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Ihis  study  was  undertaken  to  evaluate  the  modular  system  design  process  as 
applied  to  signal  processing  and  switciting  systems.  The  goals  identified  in  the 
initial  statement  of  work  included  architecture  analysis,  high  order  language 
evaluation  and  comparison,  systems  simulation,  and  hardware/software  tradeoffs. 
As  the  study  progressed,  prerequisite  and  associated  tasks  were  identified  so 
that  the  following  report  not  only  addresses  the  above  subjects,  but  the  related 
topics  of  module  descriptions,  architecture  selection  criteria  and  their 
application,  and  the  development  of  a design  methodology  for  modular  systems. 
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This  report  is  organizeo  much  like  the  contract's  "Statement  of  Work"  with  four 
sections  matching  Tasks  I - IV.  Results  are  presented  at  the  end  of  each 
section  and  are  also  combined  in  the  Summary  section  immediately  following. 

Section  5,  modular  Design  Methodology,  is  codification  of  the  experience  gained 
in  forming  the  results  of  the  preceeding  four  sections.  It  seeks  to  apply  this 
experience  witli  analytic  processes  to  the  iterative  design  process. 

Much  of  the  material  in  the  appendices  was  originally  presented  in  the  October, 
Uovember,  and  December  1976  reports.  Conclusions  presented  at  those  times  have 
not  changed;  however,  further  work  has  allowed  updating  and  expansion  of  the 
earlier  results.  (An  additional  topic,  array  processing,  was  an  outgrowth  of 
the  modularity  studies.  A brief  discussion  of  this  alternate  signal  processing 
arclii tecture  is  included  - Appendix  b).  Additional  work  in  new  areas,  primarily 
simulation  and  high  order  language  (HOL)  studies  is  also  included  in  the 
appendices. 
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Ihis  suiiimary  is  organized  into  three  sections:  (1)  A task-oriented  description 

ot  work  corresponding  to  the  Statement  of  Work,  and  including  natural  extensions 
of  that  work.  {Z)  Recommendations  for  related  study,  (d)  A summary  of  tlie 
various  appendices  to  this  report. 

1.  SUHMAKY  bY  TASK 

lask  i Architecture  Selection 

Ine  analysis  ot  the  goals  of  system  modularity  led  to  the  estaPl  i shi.ient  of 
the  bases  ot  comparison  for  architecture  selection,  principal  among  the 
potential  benefits  ot  a modular  system  is  lower  life  cycle  cost.  Ihe  cost 
over  a ib  year  cycle  originates  in  several  quantifiable  areas  whicn  group 
fairly  well  into  development  ana  acquisition  cost,  reliability,  and  per- 
formance. Inese  areas  were  first  presented  in  the  October  ly'/b  progress 
report  anu  resulted  in  the  choice  of  tlie  parallel  bus  architecture  for  botli 
signal  processing  ano  switching  systems  - though  the  analyses  were  per- 
formed separately  for  these  two  applications,  uespite  the  correspondence 
of  these  results,  application  dependency  cannot  be  overlooked.  This  point 
IS  made  clear  when  the  graphical  sumaries  of  the  architecture  selection 
process  (Section  1)  are  reviewed.  A single  fixed  system  constraint  (for  a 
specific  designer's  target  system)  could  alter  the  results. 

The  principal  argument  for  modularity  as  noted  above  is  lower  life  cycle 
cost.  Ine  several  aspects  of  the  military  design/specification/procure- 
ment/deployment/maintenance/modification/  and  support  process  are  consid- 
erably different  than  their  commercial  counterparts.  Accordingly  it  is  not 
suprising  that  different  results  witn  regard  to  system  design  criteria  will 
be  obtained.  ( fnere  criteria  reflect  a planned  lb  year  life  cycle.) 
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A separate  result  of  the  analysis  ot  signal  processing  systen  arcni tectures 
was  the  possible  role  of  tiie  array  processor,  because  the  highest  speed 
modules  in  a signal  processing  system  are  usually  at  tiie  system's  input,  an 
array  processor  employed  as  a matched  filter  or  similar  element  is 
frequently  encountered.  The  result  of  interest  (see  Appendix  b for  a 
sur.mary  description)  was  that  althougn  this  architecture  was  not  as 
supportive  of  nodularity  as  the  other  candidates,  its  reserve  capacity 
could  result  in  a total  solution  to  specialized  tasks  (in  signal 
process! nq ) . 

Task  ^ Simulation 

System  siruilation  has  verified  that  modular  systen  structures  and  elements 
of  the  type  required  for  signal  processing  and  switcning  systems  can  be 
formally  described  and  subsequently  employed  in  an  iterative  fasiiion  to 
improve  a system  design.  Examples  of  this  work  are  included  in  Section  2 
and  the  Appendices  to  this  report.  The  following  points  summarize  the  work 
of  this  section: 

(1)  Interface  simplicity  between  the  physical  (or  functional)  module  and 
its  bus  translates  into  ease,  and  hence  accuracy,  of  simulation. 

{2)  Use  of  a generally  available  simulator  is  iiighly  recommended.  Avail- 
ability supports  a potential  user's  acceptance  of  these  design  aids, 
as  their  use  is  iiiqhly  iterative  and  hence  convenience  of  access  is 
necessary . 

(3)  Related  to  item  2,  convenient  user  access  to  any  desired  level  of 
model  detail  is  desirable.  Future  work  may  be  done  for  the 
specialized  application  areas  covered  in  this  study.  This  could 
include  for  example,  modeling  of  functions  internal  to  critical 


modules. 


I ask  3 High  Urder  Language  (HUL)  Analysis 

In  response  to  the  specific  goals  of  the  statement  of  work,  several  common 
high  order  languages  were  analyzed  for  their  suitability  to  the  tasks  of 
signal  processing  and  switching  system  algoritim  development,  and  executive 
software.  A separate  topic  which  surfaced  as  a result  of  analysis  and 
review  of  the  long  term  plans  of  several  military  agencies  was  the  more 
general  question  of  language  acceptance  and  support  by  U.o.L). 

The  results  of  the  language  comparisons  are  suimarized  in  tabular  form; 
selected  topics  are  furtl\er  discussed  in  Appendix  h.  These  annotated 
descriptions  enable  a prospective  system  designer  (or  stipulating  agency  1 
to  select  the  most  appropriate  language  among  three  final  candidates  (COL, 
KL-i,  an  Spl/1)  as  a function  of  their  specific  neeas.  For  current  signal 
processing  ano  switching  systems  design,  SPL/1  was  found  to  be  most 
appropriate.  The  more  general  topics  of  language  implementation  and 
acceptance,  anu  especially  long  term  support  are  discussed  in  Section  3. 

A separate  result  of  this  study  was  the  recognition  of  the  need  for  nOL 
design  of  real  time  systems  to  be  supported  by  (i.e.  contain)  the  means  for 
transfer  to  machine  level  code.  This  escape  is  at  once  necessary  and  in 
need  of  strict  control . 


Task  4 Hardware/Software  Tradeoffs 

nardware/software  tradeoffs  are  far  more  easily  made  in  a modular  system. 
Interface  complexities  frequently  impede  such  considerations  in  other 
architectures,  ueneral  guidance  and  identification  of  corresponding  cost 
elements  in  these  trades  is  given  in  Section  ‘i.  nardware/software  trade- 
offs during  development  of  the  parallel  bus  model  (Section  resulted  in 
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the  addition  ot  a distributed  control  capability  to  this  model.  Ihe  use  of 
hardware/ software  trades  in  a system  design  context  is  contained  in  tiie 
design  methodology  description,  Section  5. 

Other  system  design  tradeoffs  are  often  important.  Itiese  include  tradeoffs 
among  implementation  techniques  (iaentified  here  as  hardv/are/haroware  and 
software/ software) . txamples  of  these  include  central  vs.  distributed 
memory,  and  alternate  control  sctiemes,  respectively.  These  related  system 
design  decisions  are  discussed  generally  in  tne  switching  system  context. 

Mouular  design  iietliodolony 

Ihe  results  or  the  architecture  selection  process  and  the  experience  gained 
in  simulation  provide  the  guidelines  for  establ  i shi  fig  a modular  system 
design  methooology.  These  design  techniques  are  complemented  by  the 
software  design  steps  at  the  various  stages  of  system  development  in  a 
suggested  procedure  in  Section  5. 
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To  be  effective,  a formalized  method  should  not  constrain  the  system 
designer  with  requirements  other  than  the  operational  and  cost  goals  of  the 
defining  agency.  It  should,  nowever,  provide  recognizable  benchmarks  for 
monitoring  progress  and  for  providing  intermediate  results  in  a form 
usuable  by  support  functions  (e.g.,  maintainability).  To  this  end,  the 
methodology  described  in  Section  b stresses  analysis  and  tabulation  of 
system  requirements,  and  suggests  specific  outputs  of  the  design  process 
for  review  at  project  Preliminary  and  Critical  design  Reviews. 

II.  RLCUIliiENUAriUhS 

Tiie  current  work,  as  defined  in  lasks  1-4,  has  been  mainly  of  an  analytic 
nature.  It  has  included  system  requirement  analysis,  architecture  and 
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language  comparative  analyses,  ana  simulation.  Ihis  has  lert  to  the 
development  of  a modular  systems  design  methodology,  tarly  application  of 
the  results  ot  this  study  has  indicated  several  areas  in  whicn  furtiier  work 
IS  necessary  to  bridge  the  gap  between  design  and  implementation,  i.e., 
methoas  to  support  tlie  user  employing  the  results  of  this  study. 

Support  ot  a uesign  systei.i  takes  many  forms,  ranging  from  the  formal 
mettiodology  oefinitions,  to  supporting  documentation  for  data  organi zation , 
system  libraries,  and  training  aids.  Three  recommendations  for  oevel opr.ient 
of  these  items  as  well  as  two  items  requiring  further  investigation 
relative  to  mUL  design  of  mouular  systems  are  briefly  describeo  below. 

uevelop  a fo rmal  mouule  library  system 

I ilany  signal  processing  and  switching  system  nodules  have  been  described  ana 

useu  as  a part  of  tne  simulations  performed  in  the  current  study,  tacli  of 
' these  modules  was  identified  by  tne  system  designer,  and  was  defined  to  tne 

level  of  detail  necessary  to  support  ttie  objectives  of  tne  canaiaate 
systems  and  simulations,  ihe  establishment  of  a formal  library  would 
include  the  following  items: 

(i)  development  of  an  indexing  and  cross-reference  system.  Candioate 

inaices  are:  (a)  software  implemented  modules  based  upon  a standard 

instruction  set  (e.g.,  puk-i1);  (b)  categori zation  by  input  (e.q., 
analog);  (c)  designs  that  are  microprocessor  based;  and  (d)  preferred 
groupings  by  level  of  field  usage,  etc. 

(<;)  development  and  test  of  a basic  set  of  signal  processing  and  switciiing 
j|  system  modules.  As  a core  set  these  would  include  control  and  timing 

, functions  required  for  each  of  these  application  classes. 
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uesign  Hetiiodoloqy  Veritication  (System  Design  Example) 

Demonstration  ana  enhancement  ot  the  methodology  described  in  Section  b is 
best  supported  through  a trial  development.  The  methodology  may  impose 
constraints  to  creativity  or  efficiency  that  are  undetected  until 
encountered  in  an  actual  development  program.  To  this  end,  the  application 
of  these  processes  to  a modular  VLF  receive  system  is  proposed.  Much 
applications  and  requirements  research  has  been  completed  for  this  system 
and,  based  upon  this  fact  and  Collins  prior  system  experience,  it  is 
reasonable  to  assume  that  application  of  the  modular  design  methodology 
would  yield  results  unaffected  by  extraneous  influences  such  as  uncertain 
systems  uesign. 

Ine  outcome  of  this  test  case  would  be  a refined  methodology  wherein  the 
input  and  output  tables,  design  review  aids,  and  simulation  routines  would 
be  tested  and  improved  as  indicated.  An  example  design  (through  completion 
of  the  preliminary  design  pnases)  would  also  be  available  as  a teaching  aid 
for  future  users. 

Iiodel  Lntiancenents 

Use  ot  the  OKSS-basea  architecture  models  to  date  has  indicated  two  areas 
where  improvements  may  be  made.  Ihese  are,  user  interface  simplifications 
(designer  to  (jH’SS  reports),  arid  expansion  of  the  set  of  system  functions 
modeled,  uevelopment  of  these  features  is  described  below. 

User/(3kSb  interfaces  occur  whenever  a file  must  be  created  or  modified,  and 
of  course,  in  the  interpretation  of  results.  File  uuilding  is  time-con- 
suming and  somewhat  error  prone  in  that  parameters  may  be  unintentionally 
changed  and  such  changes  may  be  undetected  until  a subsequent  simulation. 

This  (system  building)  procedure  would  be  greatly  simplified  through  the 
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use  ot  hURlKAh  inputs  allowing  explicit  ciiariges  to  only  those  parameters  ot 
interest.  In  a similar  fashion,  ruKlRAh  report  generators  can  be  used  to 
format  the  simulation  results  in  a very  redouble  fashion,  e.g.,  module  ano 
parameter  names  can  be  explicity  called  rather  than  tlie  current  "row/ 
column"  organization. 

System  functions  modeleo  at  present  are  common  facility  (bus)  transactions 
and  module  input/output  events  over  any  specified  period,  functions  which 
could  oe  added  include:  (a)  functions  impleriented  within  a module  (usually 

software);  (b)  queues;  (c)  bus  hierarchies;  and  (d)  peak  (i.e.,  one  tine) 
statistics  as  compared  to  averages,  (the  last  item  can  be  accomplished 
within  the  current  model.  However,  it  requires  greater  user  familiarity 
with  bhSS  than  necessary  for  the  remainder  of  the  design  aid  process.)  Tne 
alternatives  available  througti  use  of  a dual-bus  CPU  (e.g.  Pur-ll/Zu)  would 
be  explicitly  available  to  the  system  designer  as  a result  of  enhancements 
I a ) and  ( c ) . 

System  Software 

Two  nOL  design-related  topics  can  be  further  explored  in  support  of  nodular 
systems  design.  These  are  process  concurrency  as  a methodological  consid- 
eration and  the  provision  of  high  level  design  aids  such  as  'built-in 
functions"  and  "machine-like  code". 

Concurrency  is  important  whenever  the  system  designer  wishes  to  utilize  CPU 
time  i.iade  available  by  tne  hardware  execution  of  any  machine  or  algorithm 
function.  The  problem  is  complicated  wnen  code  transportability  is  a 
prerequi si te . Iiany  systems  utilize  asynchronous  ana/or  concurrent 
processes  and  require  control  of  these  processes.  Several  nUL  construc- 
tions have  oeen  developed  for  interfacing  and  controlling  these  concurrent 
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processes,  however,  these  nUL  constructions  do  not  provide  the  method- 
ologies which  lead  to  efficient  design  of  concurrent  systems.  In  parti- 
cular, when  two  processes  are  executing  concurrently,  it  is  to  be  expected 
that  one  will  complete  before  the  other  and  tine  will  be  wasted  until  the 
other  completes.  This  is  especially  aggravating  if  the  first  process  to 
complete  is  software  implementation  and  the  second  is  special  purpose 
hardware  (a  classical  example  of  this  is  magnetic  tape  1/u  functions). 

A methodology  is  desired  which  permits  the  design  of  nodular  concurrent 
software  without  ti)e  burden  of  excessive  flag  testing,  completion 
interrupts,  or  wasted  processing  time.  The  methodology  should  not  require 
excessive  care  by  the  programner  to  achieve  software  which  can  be  concur- 
rent to  other  processes  and  provide  useful  work  to  the  processor  during 
wait  periods.  It  is  expected  that  a methodology  for  concurrency  will 
inipacc  the  mUL  provisions  for  construction  of  concurrent  processes. 


built-in  functions  and  machine-like  codes  are  examples  of  methods  for 
compiler  level  stipulation  of  time-critical  functions  (or  functions  where 
some  other  dictate  of  convenience  requires  optimally  efficient  execution). 
These  functions  again  limit  code  transportability,  and  their  documentation 
is  a proper  topic  for  an  improved  design  methodology. 

iiardware-Uriented  Operating  Systems 

The  design  of  hardware-implemented  operating  systems  is  currently  being 
discussed  tor  special  purpose  applications,  such  as  real  time  signal 
processing,  based  upon  the  needs  of  communications  applications  signal 
processing,  a study  should  undertake  to  stipulate  the  features  desired  in 
such  a specialized  hardware  operating  system. 
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Primarily  because  this  study  required  the  generation  ot  analytic  "tools", 
a large  part  ot  the  results  cited  in  Sections  1-b  are  supported  by 
analyses  and/or  descriptions  whose  details  would  overly  encumber  the 
report.  Iheretore,  whenever  possible,  intermediate  results,  analyses  of 
related  topics  and,  of  course,  reference  material  sucn  as  program  listings 
were  included  in  a set  of  appendices. 

Work  which  nas  been  reportea  in  monthly  progress  reports,  and  is 
particularly  germaine  to  the  purposes  of  this  study,  can  be  found  in  the 
areas  of  arclii tecture  selection  and  language  analysis.  These  are 
described  in  Appendices  U,  G,  and  it  ( archi tecture ) and,  n (language). 

A separate  study  which  arose  as  a part  of  the  module  definition  process 
was  perfonned  on  the  applicability  of  array  processors  for  signal 
processing  in  a modular  context.  Results  were  fairly  promising  and  are 
reported  in  Appendix  b. 


Ine  remainder  of  the  appendices  contain  background  material  of  interest  to 
narrower  groups  of  users. 
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(leneric  System  Uefinition 


1.1  Introduction 

riie  principle  qoal  of  Task  1 of  the  Statement  ot  Work  is  system 
definition.  The  result  of  this  major  part  of  the  study  is  an  architecture 
description  and  its  model,  supported  by  representative  signal  processing 
and  sv/itching  modules.  This  result  is  based  upon  prior  architecture 
selection  which  was  in  turn  supported  by  development  of  sets  of  analysis 
^ oo  criteria  covering  cost,  reliability,  and  perfomance--wi th  various 

elements  within  these  categories  being  separately  weighted  for  signal 
^ processing  and  switching. 
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before  undertaking  this  extended  period  of  classification  and  analysis 
several  topics  of  a generic  nature  (to  real  time  systems)  were  considered. 

Ihese  were: 

(1)  What  are  the  bases  for  modularity?  i.e.,  "why  go  modular"? 

What  functional  level  is  most  appropriate  for  nodule  development? 

(3)  What  distinguishes  architectures,  i.e.,  what  is  generically 
signi ficant? 

(<t)  How  can  one  apply  objective  and  analytical  techniques  to  architecture 
selection,  normally  an  intuitive  or  determined-by-default  process. 

(b)  What  are  the  salient  ano  di sti ngui shi no  requirements  of  signal 
processing  and  switching  systems? 

Topics  Z-b  are  addressed  in  the  remainder  of  tnis  section.  Ine  question 
of  the  desi reabi 1 i ty  of  adapting  modularity  is  properly  raised  because  of 
the  realization  that  if  one  * me  production  and  deployment  costs  are  a 
developer's  sole  cost  critet  , uie  simplicities  of  specialization 
cormionly  outweigh  the  benefits  of  modularity.  That  is,  a system  designer 
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is  usually  not  accountable  tor  the  long  tern  cost  ot  a systein  but  rather 
is  responsible  tor  ninimun  development  and  (occasionally)  minimum  produc- 
tion costs,  however,  the  balance  ot  this  study  is  based  upon  the  attain- 
ment ot  lower  ib  year  lite  cycle  costs.  Architectures  to  attain  these 
goals  necessarily  teature  a high  degree  ot  order  - thus  hardware  that  is 
tunctionally  and  physically  nodular,  sottware  systems  tnat  coincide  with 
torthcoming  uou  standards,  and  design  methods  that  support  both  design 
review  and  maintenance  documentation  are  the  basic  elements  ot  this  study. 

1 . Z ilotiviation  tor  nodular  Architecture 

Ihe  objective  ot  any  system  design  endeavor  is  to  transform  an  established 
user  neeu  into  a functioning  system  whose  performance  attributes 
adequately  satisfy  the  users  operational  requirement,  however,  a user 
requi rei.ient,  once  established,  generally  persists  and  evolves  over  a 
period  ot  time  such  that  functional  systems  fulfilling  the  need  must 
periodically  be  modified  and  usually  expanded  and  made  tunctionally  more 
complex  to  match  the  evolving  need.  During  this  system  evolutionary 
process,  advancing  technological  means  are  applied  to  enhance  performance 
effectiveness  - a term  whicn  includes  such  factors  as  increased  perfor- 
mance per  cost  unit,  increased  reliability,  reduced  size,  expanded  range 
of  automation,  and  more  erficient  and  accurate  technical  fulfillment  of 
the  user  need  addressed.  In  fact,  tlie  evolution  of  technology  itself 
creates  expanding  user  needs  and  we  currently  find  that  development  cycle 
time  for  new  systems  is  sucn  that  by  the  time  a system  finally  enters  the 
operational  phase  its  technology  is  obsolete  and  new  deiitands  on  the  user 
are  stimulating  a new  development  cycle. 
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Clearly,  the  system  designer  must  recognize  and  accept  these  evolutionary 
forces  by  structuring  and  implementing  systems  in  such  a way  that  their 
evolution  in  response  to  need  and  technology  is  economically  and 
efficiently  achieved,  ine  concept  of  a "modular  system  architecture" 
addresses  the  reality  of  system  evolution  and  implicity  provides  the 
mechanisms  for: 

a)  adaptibility  to  evolving  use  requirements  and  tecnnology; 

b)  gradual  or  incremental  upgrade  without  unacceptable  development  cost 
or  operational  trauma; 

c)  standardization  of  functional  elements  witnout  unacceptable  penalties 
on  total  system  effectiveness. 


"Modularity"  implies  that  system  functions,  processes  or  algorithms  exist 
as  discrete  components  or  modules  which  can  oe  organized  or  reorganized 
into  a variety  of  system  structures.  Each  system  structure  composed  of  a 
collection  of  interdependent  modules  must  be  capable  of  performing  a 
distinctly  different  collective  function  while  preserving  the  functional 
and  physical  identity  of  each  discrete  module.  This  in  turn  implies  that 
a common  interconnection  scheme  exists  which  permits  the  aggregation  of 
modules  without  destroying  their  unique  identities.  The  interconnection 
scheme  must  be  selected  to  pemit  the  widest  range  of  total  system 
functions  to  be  achieved  - tliat  is,  the  interconnection  scneme  must  not 
itself  impose  constraints  on  potentially  achievable  system  performance 
over  the  set  of  possible  module  aggregations. 


There  is  a reluctance  by  industry  to  build  modular  systems.  The 
production  cost,  size,  power,  etc.,  of  modular  equipment  will  be  greater 
than  non-modular  equipment  due  to  the  penalty  of  designing  structured 
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nodules  with  common  interfaces.  In  addition,  the  responsibilities  assumed 
with  modularity  may  imply  a greater  need  for  customer  design  than  most 
users  are  actually  willing  to  undertake  - considering  such  possible  out- 
comes as  reduced  warranty,  incomplete  specifications,  etc.  Unless  the 
complete  life  cycle  cost  is  considered  which  includes  acquisition, 
operation,  and  logistic  support  the  true  cost  of  the  equipment  is  not 
seen.  It  was  suggested  at  tiie  "Mini/  Iiicro  Computer  Conference"  held  in 
ban  Francisco,  October  19/6,  that  a method  of  changing  this  reluctance 
would  be  to  purchase  a warranty  with  the  equipment  causinq  the  seller  to 
reflect  the  true  cost  of  the  equipment  at  the  time  of  purchase.  While 
this  may  not  be  the  correct  solution,  it  illustrates  the  problem  which 
both  the  industrial  and  the  military  communities  have. 


1.3  Modularity 

Modular  equipment  implementation  has  been  studied,  proposed,  and  tried 
many  times  before  and  literature  is  full  of  examples  of  the  earlier  work. 

Standard  Electronic  Modules  (SEM),  Quick  Easy  design  (QEu),  and  Register 
Transfer  Modules  (KTM)  are  three  good  examples  of  the  attempts  at  nodular 
equipment.  Ihe  RIM  group  of  modules  were  actually  implemented  and 
marketed  by  Digital  Equipment  Corporation  but  nave  not  gained  the 
acceptance  of  popular  use.  These  modules  compete  in  the  commercial  market 
place  where  adoeo  cost  of  equipment  is  a large  portion  of  the  total  cost 
of  ttie  system  due  to  the  snort  life  of  the  equipment,  because  of  the 
longer  and  more  complex  life  cycle  of  military  equipment,  additional 
acquisition  costs  for  modularity-supportive  equipment  are  small  compared 
to  total  life  cycle  cost  of  tne  system.  This  fact  should  cause  modular 
systems  to  be  more  acceptable  in  the  military  environment. 
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The  earlier  studies  have  progressed  with  electronic  technology  from 
modularity  at  the  standard  component  level  through  the  standard  minicom- 
puter. with  the  advent  of  micro-computers,  imbedded  processors  are 
practical  in  new  designs.  These  processors  implement  far  more  complex 
functions  than  previously  possible  in  modules  of  a practical  physical 
size.  As  a consequence  of  this  increased  performance  capability,  there 
exists  the  need  to  define  a standard  method  of  control  and  communication 
between  modules  whicli  will  insure  compatibility  and  preserve  performance. 
It  should  be  recognized  that  with  tiiis  type  of  system,  a nodule  may  be 
considered  as  either  hardware  or  software  and  the  two  will  most  likely 
co-exist  in  the  same  equipment.  (Ihe  most  likely  implementation  of  a 
hardware  module  will  oe  via  microprogramming.)  Therefore,  the  interface 
and  control  problem  is  different  than  that  identified  in  earlier  all- 
hardware or  all-software  module  systems. 


Ihe  O.E.U.  paper  referenced  in  Appendix  N provided  a good  basis  for 
defining  levels  of  modularity  in  hardware  systems.  Figure  l.d-1  shows  the 
relationship  between  levels  found  in  modular  hardware  and  in  modular 
software.  As  in  the  Q.E.U.  paper,  an  assumption  made  in  defining  the 
levels  of  modularity  for  this  study  is  that  tiie  elements  of  a lower  level 
can  be  used  to  define  a higher  level  but  never  the  reverse.  Hardware 

design  has  progressed  from  the  component  level  to  the  building  block 

level,  and  in  the  last  few  years  entered  the  function  level.  The  top  two 

levels  are  major  equipment  levels,  and  a form  of  unit  standardization  has 

existed  for  years  when  it  was  practical.  (Avionics  and  data  terminals  are 
examples.)  Software  design  has  progressed  at  all  levels  and  major  work 
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Figure  1.3-1.  Relationship  Between  HardwEire  and  Software  Modularity. 


has  focused  on  the  function  level.  As  a means  of  effectively  managing  and 
scheduling  a large  software  system,  modular  software  has  become  a 
necessity. 

"High  Level  Languages"  and  "Top  Down  Hrograming"  have  been  used  as  tools 
or  methods  for  designing  large  software  development  tasks  in  an  efficient 
manner.  It  should  be  noted  that  although  "Top  Down"  programming  will 
achieve  nodular  software,  ttie  use  of  a High  Urder  Language  (hOL)  does  not 
necessarily  provioe  it,  unless  used  in  conjunction  with  a "Top  Down" 
approach  to  programming. 

Ihe  method  of  defining  a module  implemented  in  either  hardware  or  software 
is  in  terns  of  its  functional  algorithm,  control,  and  1/L).  This  statement 
appears  to  be  true  at  any  level  of  modularity.  Appendix  C is  a descrip- 
tion of  the  parameters  required  when  defining  a module  at  the  functional 
level,  borne  of  the  parameters  listed  are  not  available  at  the  initial 
module  partitioning  phase  nf  the  design  process.  As  the  overall  design 
proceeds  these  parameters  become  available. 

The  control  structure  the  designer  chooses  to  tie  the  modules  together 
greatly  influences  the  success  of  the  overall  design.  At  the  functional 
level  of  modularity,  the  control  must  be  capable  of  supporting  the 
processing  power  of  the  modules  selected  i.e.  allow  distributed  control, 
yet  allow  the  system  designer  a "utility"  type  service  when  simplicity  is 
< possible,  as  is  the  case  in  low  speed  deterministic  processes. 

1 .*♦  Application  Effects 

Selection  of  an  architecture  for  both  signal  processing  and  switching 
requires  an  analysis  of  the  type  of  functions  included  in  each  system. 
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Ihese  functions  tend  to  sort  into  two  categories:  1)  Signal  Processing; 

and  ^:)  Communication  Processing.  Figure  1.4-1  lists  the  types  of 
functions  found  in  these  two  categories.  The  separation  of  switching 
functions  and  signal  processing  functions  is  vague  since  operations  of 
either  category  can  be  found  in  either  type  of  equipment  or  system. 

Still,  the  differences  shown  in  Figure  1.4-i^  for  the  two  categories 
suggest  using  different  types  of  modules  for  them.  This  concept  fits  well 
with  the  algorithm  or  function-level  partition  selected,  ilodules  at  this 
level  may  include  imbedded  processors,  each  uniquely  suited  to  solve  the 
specific  algorithm  or  function. 

The  specification  of  an  architecture  includes  the  method  of  data  transfer 
within  the  architecture.  A second  requirement  is  determination  of  the 
type  of  module  execution  control  to  be  useo  within  an  architecture. 

Figure  1.4-3  is  a table  categorizing  the  general  control  methods  available 
to  the  designer  of  equipment.  Ihe  last  category,  called  mixed  mode, 
points  to  a categorization  problem,  i.e.,  the  list  of  control  methods 
could  be  quite  long.  The  task  tiien , is  to  limit  the  number  of  control 
methods  used,  while  preserving  essential  features.  It  has  been  found  that 
centralized  control  of  the  task  allocation  routines  within  a signal 
processing  system  simplifies  the  overall  control  and  can  be  achieved, 
since  processing  times  are  fixed  intervals  in  signal  processing.  A 
switching  system  is  different,  in  that  message  arrival  rates  are  not  fixed 
so  that  decentralized  control  of  the  task  allocation  routines  is  more 
desirable.  These  differences  point  to  a need  for  flexible  control  within 
the  architecture.  Anottier  consideration  for  flexibility  is  that  although 
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TYPICAL  SIGNAL  PROCESSING  FUNCTIONS 

• BASEBAND  CONVERSION 

• CARRIER  SYNCHRONIZATION 

• BANDSPREADING 

• BIT  SYNCHRONIZATION 

• BIT  DETECTION 

• POST  DETECTION  SIGNAL  ENHANCEMENT 

TYPICAL  COMMUNICATIONS  PROCESSING  FUNCTIONS 

• SYMBOL  DETECTION 

• KEY  DEMULTIPLEXING 

• WORD  PROCESSING  - CODING,  FRAMING,  EDAC 

• MESSAGE  EXPANSION 

• MESSAGE  DELIVERY  AND  PROTOCOL 

• RECORD  KEEPING 

• EDIT/ROUTE/OUEUE 
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Figure  1.4-1.  Comparison  of  Processing  Functions. 
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SIGNAL  PROCESSOR  CHARACTERISTICS 

• HIGH  SPEED  COMPUTATION 

• DATA  INDEPENDENT  COMPUTATIONS 

• FIXED  TIME  EXECUTION  DUE  TO  NON-BRANCHING  OPERATIONS 

• HIGHLY  REPETITIVE  OPERATIONS  - SCALING,  MULTIPLY.  SUM 

COMMUNICATION  PROCESSOR  CHARACTERISTIC 

• HIGH  VOLUME  THROUGHPUT 

• FEW  OPERATIONS  PER  TRANSFER 

• FEW  ARITHMETIC  OPERATIONS 

• MANY  BRANCHING  FUNCTIONS 

• DATA  BASE 
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Figure  1.4-2.  Comoarison  of  Processor  Requirements. 


CENTRALIZED  CONTROL 

• DRIVEN  - INTERLOCKED  OR  NON-INTERLOCKED 

- CENTRAL  TIMEBASE  DRIVES  A TASK  TABLE  RESIDENT  IN  A 
CENTRAL  CONTROL  MODULE 

- DISTRIBUTED  TIMEBASE  DRIVES  A TASK  TABLE  RESIDENT  IN 
A CENTRAL  CONTROL  MODULE 

• POLLING  - INDEPENDENT  SERVICE  REQUESTS  ARE  INTERROGATED  BY 
THE  CENTRAL  CONTROL  MODULE 

DECENTRALIZED  CONTROL 

• DRIVEN  - MODULES  MAY  START  OTHER  MODULES  BY  MEANS  OF  INTERRUPTS 

• STATUS  FLAGS  - MODULES  PASS  CONTROL  BASED  UPON  COMMAND  WORDS  OR 
STATUS  FLAGS. 

MIXED  MODE 

• ANY  COMBINATION  OF  THE  ABOVE  TYPES  OF  CONTROL 
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Figure  1.4-3.  General  Control  Methods. 
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intomation  transfer  takes  place  through  the  conmon  faciliv.  certain 
interface  modules  should  be  allowed  access  to  I/U  ports  independent  of  the 
common  facility. 

for  example,  in  signal  processing,  the  amount  of  information  that  needs  to 
be  passed  from  module  to  module  tends  to  decrease  as  more  processing  is 
completed.  Ihus  a radio's  "IF"  data  is  sampled  at  a higii  rate,  filtered, 
and  only  the  results  of  this  pre-processing  operation  are  passed  to  the 
next  module  for  further  processing.  The  output  of  the  last  module  might 
be  characters  whose  output  rate  is  much  slower  than  the  original  sample 
rate  of  the  "IF"  signal. 

Another  application  dependency  is  ptiysical  in  nature.  Signal  processors 
tend  to  be  located  in  a smaller  physical  area  than  switching  systems;  the 
latter  may  contain  terminals  which  are  geograptiical  ly  isolated.  This 
study  focused  on  the  non-di stributed  operation;  however,  switching  systems 
occupying  space  equivalent  to  a medium  sized  building  were  considered.  In 
a typical  switching  system,  this  system  could  comprise  small  message 
switches,  concentrators , etc.,  whicfi  may  be  tied  by  wire-line  to  other 
geographic  locations. 

.b  Archi tectures 

The  three  architectures  selected  represent  the  generic  families  of  Serial 
(TUfl/FbM),  Matrix  (Serial,  Space  Switcn,  Separate  Control  Channel),  and 
Parallel  bus  ( Ansychronous , Interlocked).  Appendix  A contains  a descrip- 
tion of  these  architectures.  A major  portion  of  the  description  defines 
the  method  of  control  within  the  architecture.  The  control  structure  of 
the  architecture  determines  to  a great  extent  the  performance  character- 
istics of  the  architecture. 
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For  any  architecture  or  modular  design  technique  to  be  accepted  and  used, 
a certain  amount  of  flexibility  must  be  allowed  within  it.  This  closely 
parallels  the  concept  of  the  escape  mechanism  required  in  a HOL  to  allow 
lower  level  coding.  1 he  "escape"  in  the  architecture  must  allow  some 
freedom  in  module  communication,  control,  and  the  level  of  module 
implementation,  to  be  acceptable  to  a wide  variety  of  users. 

1 . D Architecture  Selection 

The  process  of  selecting  an  architecture  for  further  analysis  and  study 
pointed  to  a need  for  selection  criteria.  Appendix  D lists  tne  criteria 
developed  for  application  to  a variety  of  systems.  These  criteria  can  be 
used  as  a checklist  against  architectures  being  considered  for  other 
application  areas  to  insure  that  all  meaningful  attributes  have  been 
considered.  (Other  applications,  e.g.  control  systems,  would  naturally 
associate  a different  weighting  than  those  shown  in  Appendix  L)  for  signal 
processing  and  switching.)  The  list  was  generated  by  applying  previous 
experience  and  by  applying  new  knowledge  gained  from  a survey  of  current 
technical  literature. 

Further  practical  considerations  of  problem  sizing  established  the  need  to 
determine  the  class  of  problem  in  which  the  architecture  will  be  used. 

This  eliminates  distortions  due  to  constraints  placed  on  the  limits  of 
performance  of  any  one  attribute.  A typical  example  would  be  a system 
with  data  transfers  in  the  gigahertz  range  which  could  not  be  passed 
through  any  of  tlie  tliree  architectures;  they  are  all  unsuitable  for  this 
class  of  problem.  Appendix  E and  F describe  example  systems  of  the  class 
we  are  considering.  The  class  of  signal  processing  problem  we  have 
considered  is  of  the  encrypted  data  communication  category.  The  switching 
system  is  an  example  of  a small  military  message  switch. 
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Complete  descriptions  of  the  selection  process  are  contained  in  Appendix  G 
and  H,  for  signal  processing  and  switching  systems,  respectively. 

figures  l.b-1  through  l.b-4  are  graphs  summarizing  the  results  of  the 
comparison  process.  Ihe  results  were  analyzed  from  two  viewpoints.  Tiie 
Architecture  Comparison  Sunnary  Figures  l.b-1  and  1.6-3  were  achieved  by 
sunning  the  score  by  attribute  (1st,  3nd,  3rd)  and  weighing  the  attributes 
by  relative  importance.^  Ihe  latter  weigiiing  is  always  application 
dependent.  Ihe  results  shown  on  this  chart  did  not  clearly  reflect  a 
general  advantage  to  be  obtained  by  using  any  of  the  three  arciii tectures . 

A second  way  to  look  at  the  comparison  process  is  to  sun  the  best/worst 
choices  by  attribute  (see  Figures  1.6-2  and  1.6-4).  These  charts  are  more 
meaningful  because  they  more  clearly  reflect  the  advantages/di sadvantages 
of  using  a given  architecture.  The  parallel  bus  architecture  described  in 
Appendix  A-1  was  separately  selected  for  future  modular  systems  design  for 
both  signal  processing  and  switciiing  systems. 


^The  architecture  selection  process,  briefly  described,  consisted  of 
separate  specialists  developing  attributes  in  3 areas:  cost,  reliability,  and 

performance.  The  architectures  were  compared  on  a "by  attribute"  basis,  and 
scored  best,  median,  worst.  The  specialists  further  indicatd  the  most  and  least 
important  attribute  in  each  area;  in  the  final  sumations  those  items  were 
respectively  weighted  doubly  (most  important)  and  disregarded  (least).  The 
weighting  of  best-median-worst  for  each  attribute  was  converted  to  a numercial 
4-2-1  for  the  signal  processing  raw  summaries,  however  "best",  "worst"  was  used 
directly  for  te  comparisons  shown  in  Figures  1.6-2  and  1.6-4.  Appendices  G and 
M describe  the  comparison  process  in  greater  detail  for  signal  procesing  and 
switching  systems  respectively. 
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Figure  1.6-1.  Architecture  Comparison  Summary  for  Signal  Processing. 


OF  •WORST"  CHOICES  BY  ATTRIBUTE  % OF  BEST  ’ CHOICES  BY  ATTRIBUTE 


1.6-2.  Best/Worst  Comparison  by  Attribute  for  Siqnal  Processinq. 
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Figure  1.6-3.  Architecture  Comparison  Summary  for  Switching  System. 


legend 

M - MATRIX 
B - parallel  BUS 
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Figure  1.6-4.  Best/Worst  Comparison  by  Attribute  for  Switching  Systems. 
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d.U  SIMULA! lOu 

i!. . 1 Selection  of  UHSS 

Ihe  IbM  General  Purpose  Simulation  System  (LiPSS)  was  used  as  the  simu- 
lation system  for  this  study.  uPSS  provides  a language  which  is  concise 
and  adaptable  to  a wide  range  of  proolens.  GPSS  is  well  documented  thus 
making  the  learning  and  use  of  it  very  accommodating.  It  provides 
standard  reports  for  all  ioentifiea  facilities,  queues,  storage,  etc.  It 
also  provioes  instructions  to  create  specific  formats  and  house  special- 
ized reports  if  the  standard  printouts  are  not  sufficient.  "HELP" 
instructions  to  access  designer  coded  FORTRAN  routines  or  machine  coded 
routines  are  also  available  if  more  unique  operations  are  required  beyond 
the  uPSS  instruction  set. 

2. 1 OPSS  Description 

Tiie  IBll  General  Purpose  Simulation  System  (GPSS)  provides  a flexible  tool 
for  the  analysis  of  systems  of  a complex  logical  and  procedure  oriented 
nature.  It  provides  an  effective  means  of  testing,  evaluating,  and 
weighing  alternatives  of  a proposeu  system.  The  models,  however,  are  not 
the  precise  analog  of  the  actual  systems,  but  rather  a symbolic  repre- 
sentation of  the  system. 

GPSS  is  a generalized  language  which  incorporates  a series  of  entities 
which  are  described  by  GPSS  statements  to  represent  the  features  of  the 
system  to  be  modeled.  These  entities  are  divided  into  six  categories. 
Basic,  equipment,  computational,  statistical,  reference,  and  chain.  Refer 
to  table  2.1-1  for  the  types  of  entities  in  each  category. 
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Category 

Switching  System  Examples 

1.  basic  entities 

1. 

Transactions 

Message  traffic 

2. 

blOCK 

Operations  on  message  traffic 

2.  Equipment  entities 

3. 

Faci 1 i ties 

CPU,  disc,  tape,  etc. 

4. 

Storages 

Memory,  secondary  storage 

b. 

Logic  Switches 

Events  that  block  traffic 
(circuit  down  or  on  hold) 

J.  Computational 
enti ties 


4.  Statistical 
enti ties 


b.  Arithmetic  Variables  Any  computation  of  arithmetic 

conihi  nations 


/.  boolean  Variables  Single  decision  on  many 

attributes;  i.e.,  circuit  dov/n 
ana  type  of  message. 

b.  Functions  Computation  of  rate  of  message 

traffic. 


9.  Queues 


Traffic  to  output  circuit,  to 
disc  storage,  or  tape  storage. 


lu.  distribution  Tables  Additional  statistics,  i.e., 

message  type  distribution  by 
tine. 


Reference  entities  11. 

Saveval ues 

General  use  for  recording  data 
at  one  time  and  referred  to  at 
another. 

12. 

Matrices 

Circuit  type,  status,  etc.  by 
line  (line  tables) 

fa.  Chain  entities 

13. 

User  Chains 

Message  retrievals 

I**. 

Groups 

Accounting  of  multi -routed 
messages. 

Faule  cF.l-l  Entities 
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Iho  most  coniionly  useo  entities  are  the  '' transacti on"  and  "block" 
entities,  both  classified  as  "basic"  entities  in  the  GkSS  system  (see 
Category  1,  Table  ti.Z-i).  A nodel  must  as  a minimum  oe  represented  by 
blocks  and  transactions,  the  latter  must  be  generated  to  stimulate  the 
system,  uther  entities  are  used  as  required  to  represent  the  system 
features.  Once  the  system  is  described  in  terms  of  ueSb  blocks, 
transactions  which  represent  traffic  or  data  are  created  by  the  program, 
and  are  moved  through  the  specified  blocks,  executing  the  actions 
associated  with  each  blocK. 

A clock  is  maintained  by  GPSS  that  records  the  current  simulation  clock 
tine.  ►Jitn  tnis  clock,  GkSS  may  execute  simulated  events  in  the  correct 
time  sequence.  Ihe  clock  tines  are  maintained  in  integer  values,  however, 
they  are  not  incremented  in  the  conventional  manner,  but  are  up<lated  to 
the  value  at  which  the  next  event  is  to  occur.  For  example,  if  the 
current  clock  time  is  z,  ana  the  next  event  is  to  taxe  place  at  /,  the 
clock  time  is  incremented  by-  five  units.  The  time  units  do  not  represent 
any  specific  unit  of  time.  It  iiay  represent  any  unit  of  tine  needed  to 
obtain  modeling  precision.  Unce  tne  time  unit  has  been  defined  to  be  a 
specific  unit  of  time,  all  time  requirements  in  the  model  must  be 
expressed  in  the  same  terms. 

uKSS  also  maintains  a number  of  standard  statistics  of  the  model  being  run 
depending  on  the  entities  being  used.  These  statistics  are  available  at 
the  option  of  the  user  to  be  automatically  printed-out  at  the  end  of  a 
run,  selectively  printed  out,  or  reformatted  (within  the  GPSS  format 
statement  capabilities). 
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A more  detailed  description  may  be  obtained  tron  the  Idll  General  l^urpose 
Siuulation  System  V Users  Manual  ( Sh^!U-Ubbl-l ) . 


ZA.d  System  U sed 

GHSS  V is  resident  at  the  Western  Computer  Service  Center,  Rockwell 
International  in  uowney,  California.  Five  IbIl/J7U  Model  Ibt)  computers  are 
installed  there  with  various  equipments  that  are  stiared  and/or  switchable 
frou  one  model  lo«  to  another. 

Input  to  the  center  is  made  via  batchinq  on  a uATAlUU  { card/pri nter ) 
terminal  located  at  the  Collins  Radio  Newport  Computer  Center  in  Newport 
ueach,  California,  or  via  TSU  terminals  located  throuqiiout  Collins. 

6 A Model  Description 

Mie  architecture  selected  for  modeling  was  the  parallel  bus  archi tecture , 
as  described  in  Appendix  A-1. 

The  model  is  a representati on  of  the  parallel  bus  structure.  The  primary 
aspects  of  the  bus  operation;  next  master,  bus  master,  and  priority  were 
modeled  while  the  detailed  logic  flow  (see  bus  acquisition  sequence. 
Appendix  A-1,  Figure  A.l-b)  of  the  bus  activity  was  not  represented. 
Modeling  the  detailed  logic  of  tlie  bus  activity  was  determined  to  be 
unnecessary  because  (1)  the  parallel  bus  architecture  closely  resembles 
the  operation  of  known  equipment  (RuH-ll  Unibus)  and  (2)  the  study  of  the 
bus  utilization  and  congestion  due  to  data  transfer  and  communications  was 
found  to  be  unnecessari ly  delayed  when  a detailed  logic  representation  of 
the  bus  was  used. 

The  model  can  accommodate  up  to  bU  modules  controlled  by  various  methods 
as  described  in  Section  if.J.l.  tach  nodule  is  assigned  a priority  which 
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represents  position  on  the  bus  which  in  turn  determines  which  module  is  to 
be  granted  control  ot  the  bus.  However,  in  order  to  be  granted  control  of 
the  bus  (bus  master),  the  module  must  have  already  attained  next  master 
status.  Priority  position  thus  provides  for  attaining  next  master  status 
rather  than  bus  master.  Once  next  master  status  is  attained  it  is  not 
relinquished  to  the  higher  priority,  next  master  status  proceeds  to  bus 
master  status  as  soon  as  it  is  relinquished.  Tins  model  allows  only  a 
single  word  transfer  during  each  bus  mastership  whereupon  tlie  module 
relinquishes  control  and  again  bids  for  bus  control  by  bidding  for  next 
mastership,  hith  this  sequence,  a module  does  not  monopolize  the  bus  with 
any  data  tra/isfer,  nor  does  a tiigh  priority  nodule  continuously  receive 
bus  control.  The  highest  priority  nodule  is,  however,  guaranteed  control 
every  other  cycle  time,  if  desired. 

The  bus  operates  on  a master-slave  relationship  in  that  for  each  control 
signal  issued  by  the  master,  a response  must  be  received  from  the  slave 
Idestination  module).  In  this  model,  the  slave  always  answers,  whether  it 
is  busy  or  not.  Itie  model  maintains  a queue  for  each  called  module,  thus 
maintaining  statistics  on  its  activities.  A separate  queue  is  also 
maintained  for  output  in  the  event  that  separate  control  is  issued  to  a 
module  for  output  ot  data.  A call  made  to  a module  that  is  currently  busy 
will  thus  be  held  in  queue  until  ttie  current  process  is  complete.  The 
process  includes  such  activities  as  input  and  output  of  data  on  the  bus 
(module  to  module),  it  cot.iiion  memory  is  available  the  intra-algorithm  use 
Of  memory  by  the  module,  and  the  estimated  module  execution  time.  These 
processes  are  done  serially  and  statistics  are  recorded  on  each. 
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Ihis  mo<lel  Is  a general  purpose  model  in  that  it  is  driven  by  parameter 
specification  of  each  individual  module.  These  parameters  are  described 

in  Section  Z.j. 

The  statistics  accumulated  during  the  simulation  are  presented  at  the  end 
of  the  simulation  run.  The  printout  is  in  a standard  GPSS  format.  Tne 
report  types  are  described  in  section 

Verification  of  the  model  was  accomplished  in  two  levels.  Ihe  first 
level,  was  the  verification  of  results  as  each  option  (parameter  setting) 
was  added.  These  results  (printouts)  were  compared  to  the  expected 
results  of  the  option.  Ine  next  level  of  verification  was  accomplished  by 
selecting  several  specific  sets  of  modules  and  comparing  the  results  cf 
the  simulation  with  hand  calculated  results.  For  tne  deterministic  case 
of  signal  processing  these  comparisons  were  exact. 

The  Switching  System  bus  utilization  was  estimated  by  computing  an 
estimation  of  the  total  characters  tranferred  over  the  bus.  This  was  done 
by  using  the  mean  values  for  total  messages  handled,  characters  per 
message,  number  of  output  messages  per  input  message,  and  the  time 
required  per  transfer.  As  an  example  of  these  steps,  the  busy  hour  is 
tabulated  below.  (PLRS,  Position  Reporting  Location  System,  defines  a 
separate  class  of  fixed-length,  perishable,  messages  for  which  statistics 
were  kept  separately.) 

Total  Messages  i^U,UUU  PLRS  + i!5uu  non-PLRS 

Mean  characters/message  X au  X 

characters  in  l,bUO,UUU  auU,UUO 

output  messaqe/i nput  3,u 
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l,bUU,UOU  auu.uoo 
X 3.0  X 4.U 

Total  characters/hour  6,UbU,UUU  + 3,<iUU,UUU  = y,2!ttu,UUU 
lota)  characters/second  = 2577.7 

2577  ch/sec  X 5.5  usec/ch  X iuu;^  = 1.42b 

In  the  simulation  ot  the  busy  hour  characteri sties , the  total  1/U  Data 
Iranster  v/as  listed  as  l.blt,  which  verifies  the  above  calculation. 

2.J  Parameter  Description 

The  model  ot  the  parallel  bus  architecture  will  accomodate  ou  separate 
modules  and  operates  on  each  module  according  to  its  individual  parameter 
specification.  Eacti  ot  the  modules  may  be  defined  by  up  to  21  different 
parameters.  Fourteen  parameters  are  optional  (have  known  default  to  zero 
conditions)  and  seven  parameters  must  always  be  specified.  These  are 
identified  (*)  in  the  parameter  list  in  Table  2.3-1.  As  shown  in  Table 
2.3-1,  there  are  currently  21  parameters  that  define  a module;  ID  byte 
size  parameters,  b halfword  size  parameters,  and  5 full  word  size 
parameters.  Ihese  three  sizes  were  defined  according  to  information 
length  requirements  of  each  parameter. 

2.3.1  byte  parameters 

1.  Module  Activation:  This  par="iieter  defines  whether  the  nodule  is  to  be 

included  in  the  simulation  run.  It  can  either  be  a "1"  for  active  or 
a "u"  for  inactive.  Ihus,  modules  may  be  defined*  and  activated  as 
required  prior  to  a simulation. 


* A module  sunriary,  lable  2.6-J,  lists  a representative  set  of  signal  processing 
modules. 
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MAXIMUM  QUEUE  LENGTH  i?s77 17 


TABLE  2. 3- IB.  HALFWORD  Parameters. 


MATRIX  NAME  - HPARM 
ROWS  - MODULES  1 THRU  60 
COLUMNS 

1 NO.  OF  INPUT  WORDS 

2 INPUT  READ  TIME,  EACH  INTEGER  = 50  NS 

3 NO.  OF  OUTPUT  WORDS 

4 OUTPUT  WRITE  TIME,  EACH  INTEGER  = 50  NS 


5 

NO. 

OF 

INTERNAL 

READS  FROM 

COMMON 

MEMORY 

6 

NO. 

OF 

INTERNAL 

WRITES  FROM 

COMMON 

MEMORY 

12877.18 


TABLE  2.3-lC. 


FULLWORD  Parameters. 


MATRIX  NAME  - FPARM 
ROWS  - MODULES  1 THRU  60 

COLUMNS  (NOTE:  EACH  INTEGER  = 50  NS,  e.g.,  5000  = 250  pS) 

1 MODULES  START  CYCLE  TIME 

2 MODULES  OUTPUT  INTERVAL 

3 MODULES  PROCESSING  TIME 


4 

5 


START  TIME  OFFSET 
OUTPUT  TIME  OFFSET 


12877. J9 


} 


J 
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i.  Priority:  This  parameter  (letines  the  module  priority;  that  is  its 

position  on  the  bus  which  determines  the  priority  order  of  obtaining 
next  master  status,  “u"  to  "127“  may  be  specified,  where  the  highest 
number  defines  the  highest  priority. 

3.  Type  of  Control:  Currently,  four  types  of  control  may  be  specified  in 

this  model.  Since  this  is  a nodule  parameter,  a mix  of  controls  may 
be  specified. 

0 "u"  = decentralized  control:  In  tins  type  of  control,  the  module 

assumes  tiie  responsibility  of  scheduling  itself.  No  bus  activity 
results  from  this  type  of  control. 

0 "1“  = centralized  control:  A built-in  control  nodule  in  the 

model  schedules  the  modules  according  to  each  module's  time 
parai.ieters  (see  fullword  parameter).  It  simulates  the  generation 
of  an  interrupt  vector  on  tne  bus  and  records  its  bus  activity. 

0 "2"  = Module  Interlock:  Inis  type  of  control  is  provided  by 

another  module,  at  tlie  completion  of  its  function  (at  output). 
Thus,  module  "a"  is  said  to  be  interlocked  with  "b"  when  the 
completions  of  b's  function  is  required  to  initiate  "a".  That 
nodule  number  is  specified  in  byte  parameter  «.  More  than  one 
module  may  be  interlockeo  in  a pipeline  fashion.  Interlock 
modules  may  be  used  to  simulate  software  modules  that  comprise  a 
primary  module,  such  as  a CPU  module. 

0 "3"  = Module  Call:  This  option  provides  the  capability  for  a 

module  to  receive  control  from  another  module,  similar  to  control 
type  2 above.  The  ca’led  module  control  type  parameter  is  set  to 
a 3,  and  its  module  number  is  set  in  the  calling  module  para- 
meters (see  byte  parameter  y and  refer  to  Fig.  2.3-1) . Up  to  six 
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9 \ , I 

I 

f 

' BYTE  PARAMETER 

9 • K 


! 


CALLED 


(CONTROL  type  31 


BYTE  PARAMETER 
9 - K 


TABULAT(ON  OF  SUMMATION  OUTPUT  FROM  J TO  K 

IF  J S OUTPUT  IS  GREATER  THAN  K S INPUT  TIME,  J’S  OUTPUT  IS  USED 
IF  K'S  INPUT  IS  GREATER  THAT  IS  USED 

TABULATIDN  OF  SUMMATION  OUTPUT  FROM  M TO  K 

IF  M'S  OUTPUT  IS  GREATER  THAN  K'S  INPUT  TIME,  M'S  OUTPUT  IS  USED. 
IF  K'S  INPUT  IS  GREATER  THAT  IS  USED 


20377. 8 


Figure  2.3-1.  Module  Call  Option. 
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calling  modules  may  be  specified.  The  model  tabulates  all  the 
transfer  times  of  the  calling  modules  output  data  to  the  called 
module.  It  selects  the  greater  of  the  two  access  times  (calling 
versus  called)  for  data  output. 

4.  [ype  of  Iiemory  Use:  Ihe  model  currently  has  a built-in  common  memory 

which  has  a single  parameter  (specified  as  a system  level  parameter) 
which  specifies  the  memory  access  time.  Usage  of  the  common  memory  by 
a module  is  tabulated  using  the  memory  access  time.  However,  if  the 
module  access  tine  specified  is  greater,  that  time  will  be  used.  Each 
module  nay  specify  one  of  four  types  of  common  memory  use  as  follows: 

0 "u"  = distributed  memory;  common  memory  not  used. 

0 "i"  = common  memory  input;  data  is  input  from  common  memory. 

0 ‘V‘‘  = common  memory  output;  data  is  output  to  coixion  memory. 

0 "3"  = common  memory  both;  data  is  both  input  from  and  output  to 

common  memory. 

b.  Input/Output  lime  Distribution  Ilodifier:  Ihis  parameter  specifies  a 

continuous  numerical  function  that  is  used  as  a modifier  to  the 
specified  module  start  cycle  and  output  interval  (see  fullword  para- 
meter description)  to  provide  a variable  start/output  cycle. 

Currently,  seven  functions  are  available  (see  Table  I'.S-l). 

b.  Module  Time  Distribution  Modifier:  Ibis  parameter  specification  is 

similar  to  (b)  above  except  that  it  is  used  as  a modifier  to  the 
specified  module  processing  time  (see  fullword  parameter  description). 

7.  I/u  uata  Distribution  Modifier:  This  parameter  specification  is 

similar  to  b above  except  that  it  is  used  as  a modifier  to  the 
specified  module  input  word  and  output  word  count  (see  halfword 
parameter  description). 
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i-lodule  Interlock  Nunoer:  Ihis  paraneter  is  et  in  conjunction  with 

control  type  equal  to  (refer  to  control  type  parameter  J description 
above),  fhe  module  number  of  that  nodule  which  provides  the  control 
is  specified. 

nodule  Number,  Output  Directed  lo:  Ihe  module  number  to  which  output 
IS  directed  to  (called  module)  is  specified  in  this  parameter.  The 
model  tabulates  the  output  time  (the  greater  of  tne  two  I/u  times) 
under  the  called  module  statistics.  Control  to  the  nodule  may  also  oe 
provided  if  the  control  type  paraneter  of  the  called  module  is  set  to 
d (see  type  of  control  above). 

tlaximum  Uueue  Length:  Specification  of  this  parameter  will  terminate 

the  simulation  abnormally  when  and  if  the  conditon  is  met.  Uueue 
statistics  ror  that  nodule  will  be  printed  followed  by  the  normal 
report  format  (statistics  will  be  tabulated  up  to  point  of  termina- 
tion). Noriiially  in  real  time  systems  such  as  signal  processing,  any 
module  in  the  stream  must  complete  its  processing  before  being  called 
again,  otherwise  it  will  not  catch  up  again.  The  signal  processing 
modules  are  all  initially  set  to 


L.i.i  halfword  farameters 

1.  Number  of  Input  words:  Ihis  parameter  specifies  the  number  of  words 

to  be  input  under  this  module's  control.  If  a modifier  has  been 
specified  (byte  parameter  7),  this  parameter  indicates  the  mean  value 
of  the  number  of  words.  These  words  are  input  on  each  Input  Start 
cycle. 

f-  l.  Input  Read  Tine:  inis  parameter  specifies  the  input  tine  for  each 

I 

word  input  oy  the  module.  Each  integer  specified  represents  bu  X 
_g 

lu  seconds.  This  tine  plus  the  bus  time  (system  paraneter)  is  the 


i 


2-14 


J 


I 

t 


1 


I 


I 

I 

i 


i 


actual  t)us  access  time.  It  common  memory  input  is  specified,  the 
input  read  time  is  compared  with  the  common  memory  access  time  (system 
parameter),  and  the  largest  of  the  two  plus  the  bus  time  is  the  actual 
bus  access  time  used,  i.e..  Access  Time  = I/U  tine  + bus  cycle  tine, 
where  I/u  time  = the  larger  I/U  time  of  the  source  and  destination 
modules. 

d.  Number  of  Output  Noros:  I his  parameter  specifies  the  number  of  words 

to  be  output  under  this  module's  control.  If  a modifier  has  been 
specified  (byte  parameter  /),  this  parameter  represents  the  mean 
values  of  the  number  of  words  to  be  output.  These  words  are  output  at 
each  Output  interval  or  each  time  the  module  is  provided  control  via 
the  interlock  or  call  method  of  control. 

4.  Output  ^Jrite  Tine;  This  parameter  specifies  the  output  time  for  each 
word  output  by  the  module,  tach  integer  specified  represents  bu  x 
iU  seconds.  This  time  plus  the  bus  cycle  time  (system  parameter)  is 
the  actual  bus  access  time.  If  common  memory  output  is  specified,  the 
output  write  time  is  compared  with  the  common  memory  access  time 
(system  parameter),  and  the  largest  of  the  two  plus  the  bus  cycle  time 
is  used  as  tiie  actual  bus  access  time  for  each  word. 
b,fa.  Number  of  internal  common  reads,  writes  from  common  memory:  These 

parameters  specify  the  number  of  reads  and  writes  to  common  memory 
used  internally  by  the  module  for  such  tilings  as  indicators,  flags, 
temporary  storage,  etc.  The  actual  bus  access  time  per  word  is 
determined  identically  to  the  read  (or  write)  time  above. 
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l.s.6  Kullword  Harameters 


I,  Module  Start  Cycle  lime:  This  parameter  specifies  the  rate  at  which 

_9 

tiie  module  is  provided  control.  Lach  integer  represents  Su  x 10 
seconds.  As  an  example,  it  the  module  start  cycle  time  is  hZb  x 10"*^ 
seconds,  the  parameter  is  set  to  li^buu.  If  a modifier  is  specified 
(see  byte  parameter  b),  the  time  specified  must  represent  a mean  time. 
Ihe  first  interrupt  vector  is  sent  at  time  = 0. 

/t.  Module  Output  Interval:  This  parameter  specifies  the  rate  at  wiiich 

the  module  is  to  output  data.  This  interval  must  equal  to  or  be  a 
multiple  of  the  module  start  cycle,  tach  integer  also  represents  bO  x 
10  seconds.  If  a modifier  is  specified  (see  byte  parameter  b),  the 
time  specified  must  represent  a mean  time.  At  startup  time,  the  model 
does  not  send  the  interrupt  vector  at  time  = 0,  but  begins  the  output 
interval  at  time  = 0 plus  output  interval. 

J.  ilodule  processing  lime:  This  parameter  specifies  the  processing  time 

required  uy  the  module  each  time  it  is  started  (refer  to  full  word 

_ (j 

parameter  1).  Each  integer  also  represents  5u  x 10  secotids.  If  a 
modifier  is  specified  (refer  to  byte  parameter  b),  tne  time  specified 
must  represent  a mean  time. 

Start  lime  Offset:  This  parameter  defines  a value  which  the  start 

cycle  time  be  offset  from  real  time.  As  an  example,  if  the  offset  is 
b and  the  start  cycle  time  is  lOu,  the  first  interrupt  vector  will  be 
generated  by  tne  model  at  time  o plus  b.  Hie  succeeding  interrunts 
will  then  ne  generated  at  time  0 plus  lOb,  time  0 plus  ^lOb,  etc. 
b.  output  Time  Offset:  The  parameter  defines  a value  in  which  the  output 

interval  is  offset  from  real  tine.  Using  the  same  example  above  for 
the  output  interval  and  remembering  that  output  interrupt  does  not 
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oegin  at  tine  = U (refer  to  fullworci  parameter  2.  above),  tne  first 
interrupt  vector  will  be  generated  at  tine  U plus  b plus  100. 

by  stem  Parameters 

Several  parameters  are  specified  at  the  system  level.  These  include  the 

bus  speed,  the  common  memory  access  time,  and  the  length  of  simulation 

tine . 

1.  bus  Cycle  lime:  This  system  parameter  represents  the  speed  of  the 

bus.  The  ous  speed  is  currently  specified  at  4 linz.  This  represents 
^;bO  X iu"  seconds,  maximum  bus  access.  At  bu  x 10'^  seconds  per 
umt,  the  integer  b is  currently  set  as  the  bus  cycle  time.  This 
value  is  added  to  the  I/u  rates  specified  in  each  nodule  when 
performing  word  transfers  on  the  bus. 

2.  Conuon  Memory  Access  lime:  Inis  system  parameter  represents  the  speed 

of  a common  memory  unit  on  the  bus.  Currently  a 1 x lo’^  second  unit 
is  used,  or  ^;o  units.  If  common  memory  is  specified,  this  value  will 
be  used  as  the  I/O  time  if  it  is  greater  than  the  specified  nodule  I/O 
times. 

J.  Length  of  Simulation  Run:  This  parameter  specifies  the  length  of  tne 

simulation  run  and  is  represented  by  tv/o  parameter  values.  Tne  first 
THtKJ  specifies  a certain  period  of  time,  i.e.,  for  a luu  ns  period, 
TKtku  is  <iOOoOOO.  The  second  parameter  TIME  specifies  the  number  of 
periods  to  repeat.  Thus,  if  set  to  b,  tne  total  run  time  equals  to 
bOO  ns. 
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Statistical  Printouts 


The  simulation  printouts  provided  are  categorized  as  (1)  Configuration 
Parameters  and  (z)  Performance  Characteristics.  Ihe  former  lists,  by 
parameter  type,  all  the  parameter  values  described  in  section  Z.3  for  each 
of  the  modules  defined.  The  active  indicator  (set  to  1)  describes  the 
modules  activated  in  the  simulation.  The  performance  characteristics 
provide  the  tabulation  and  statistics  as  a result  of  the  simulation,  tach 
of  the  characteri sties  are  described  in  the  following  sections. 

Z-.*!.!  Input/uutput  Average  Times  ( lAVC) 

Ihis  report  is  a sui.nary  of  the  I/U  tines  of  each  of  tne  nodules 
activated.  It  provides  the  average  times  for  input  data  (halfword 
parameter  1),  output  data  (halfword  parameter  d),  internal  reads  (halfword 
parameter  4)  and  internal  writes  (halfword  parameter  5).  The  neasure.nent 
of  time  is  from  the  beginning  of  each  1/u  block  transmission  to  its 
completion.  It  thus  includes  bus  tine  as  well  as  an.y  wait  times  due  to 
higher  priorities.  This  measurement  is  accumulated  throughout  tne 
simulation  run.  At  the  end  of  tne  run,  averages  are  taken  of  each  type  of 
l/U  block  transmission  by  dividing  the  total  1/U  tine  accumulation  by  the 
total  number  of  block  transmissions. 

Also  included  in  tiiis  report  is  the  average  wait  tine  for  nextmaster  and 
module  tine  difference.  The  average  wait  time  for  nextnaste.  is  a 
measurement  from  the  tine  the  module  first  tries  to  obtain  next  mastership 
to  the  time  it  finally  obtains  it.  Ttiese  times  are  accumulated  each  time 
next  mastership  is  required  which  is  done  at  eacti  word  transferred 
according  to  the  system  definition.  The  average  is  then  determined  at  the 


end  of  the  simulation  run. 
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The  time  oitterence  is  determined  at  the  end  of  the  simulation  run  by 
summing  the  average  1/u  times  ana  the  specified  module  time  (fullword 
parameter  d),  and  subtracting  this  sum  from  the  start  cycle  time  (fullword 
parameter  1). 

Ihese  times  are  all  represented  in  units  of  bd  x lu”^  second. 

Interlock  tiodules  (LUCKS) 

This  report  provides  a summary  of  these  modules  that  were  interlocked  for 
the  simulation  run.  It  provides  the  chain  of  modules  (numbers)  beginning 
with  the  start  module,  and  will  report  up  to  seven  interlocked  modules. 

For  example,  if  the  system  lias  been  defined  to  interlock  nodule  3 by 
nodule  and  nodule  'i  by  module  3;  the  report  will  show  nodule  as  a 
start  module  interlocking  (passing  control)  to  module  3 which  in  turn 
interlocks  (passes  control)  to  module  4.  The  report  will  also  show  nodule 
J as  a start  module  interlocked  to  nodule  4. 

The  total  I/U  times  and  module  times  are  accumulated  for  all  the  inter- 

_y 

locked  nodules.  This  information  (expressed  in  units  of  50  x To 
seconds)  when  summed  provides  the  total  time  required  by  these  modules; 
and  when  compared  with  the  total  elapsed  tine  of  the  run,  it  provides  a 
ratio  of  those  nodules  real  time  requirement.  The  I/U  and  module  tii.ies 
are  reported  for  all  active  modules. 

^'.4.3  Call  Modules  (CALLS) 

This  report  provides  a list  of  the  modules  (calling  modules)  sending  data 
to  a particular  module  (called  module).  Up  to  six  calling  nodules  are 
tabulated.  I/U  totals  are  reported  by  calling  modules  and  by  the  called 
module.  Total  module  processing  time  is  by  called  nodule  only.  The 


I 

If 
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called  nodule  I/u  and  processing  tine  totals  are  reported  ror  all  active 
nodules. 


$ 


r 
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bus  Time  ( TIMl ) 

This  report  provides  a summary  ot  the  actual  total  time  of  bus  utilization 
by  module.  The  bus  time  utilization  for  each  nodule  is  shown  as  a total 
unit  time  (each  unit  equals  bO  x lu  sec)  and  as  a percentage  of  the 
total  bus  time.  The  percentage  is  shown  in  hundredth  of  a percent.  For 
example,  if  under  the  Percent  column  a value  of  112  is  shown,  it  would 
read  as  112  hundredths  of  a percent  or  1.12  percent.  The  last  two  rows 
(row  bl  and  b2 ) are  the  totals  of  the  control  module  (when  centralized 
control  is  specified)  and  the  system  totals  (sums  of  all  modules  unit  tine 
and  percent  of  bus  time)  respectively.  If  centralized  control  is  not 
specified  in  any  of  the  modules,  row  61  would  not  be  printed  or  would  be 
equal  to  zero. 

2.4.5  Comfiion  Memory 

This  report  provides  the  percent  of  total  bus  time  (of  all  transmissions 
to/from  common  memory)  by  the  modules  that  utilize  the  common  memory. 

Along  with  tne  total  percent  utilization  of  time  are  percent  utilization 
of  time  by  I/u  data  transfers  and  by  internal  read/writes  of  the  modules. 
Analysis  of  these  statistics  is  a part  of  tne  centralized  vs.  distributed 
memory  trade  study. 

2.4.6  Wait  Statistics 

This  report  is  a standard  UPSS  report  on  using  the  Queue/depart  entity  of 
GPSS.  (Jueues  1-faU  are  the  wait  statistics  for  module  starts  (refer  full 
word  parameter  1)  and  bl  to  12U  are  the  wait  statistics  for  module  outputs 
(refer  fullword  parameter  2)  for  modules  1-bU  respectively. 
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When  using  the  maximum  queue  length  parameter  feature  (refer  to  byte 
parameter  lu),  an  individual  report  is  generated  when  the  maximum  queue 
length  specified  is  exceeded.  The  standard  reports  are  then  generated 
consisting  of  statistics  up  to  the  abnormal  termination. 

User  Interface 

1 he  following  sections  are  instructions  on  (1)  how  to  access  the  37u 

r 

system  to  run  the  GPSS  model  and  (H)  how  to  activate  and/or  redefine  or 

I 

add  modules  in  the  model . 

,U 

(d.b.l  System  Access 

Ihis  description  is  based  on  an  IBIl  3/u  16a  main  frame  with  US/VS^^  TSO 
System  and  UHSS  Version  V as  well  as  the  delivered  simulation  program 
(written  in  GKSS)  in  its  files.  The  latter  may  be  resident  in  only  the 
user  (TSU)  file.  The  file  names  and  procedures  referenced  in  tfie 
following  description  are  those  cataloged  at  Computing  Service,  Rockw*-’! 
International,  Western  Region. 

iii.b.i.l  Cataloged  procedure  and  JCL  requirements 

The  GrSS  Version  V program  modules  leside  in  a private,  cataloged  data  set 
named  ASYS.CaRSS  at  Computing  Services.  This  data  set^nust  be  referenced 
in  a JObLIb  or  STERLIb  statement  to  access  the  (jRSS  programs.  Ihe  program 
module  named  UAGOIV  shoulu  be  entered  on  the  EXEC  statement.  For  other 
JCL  requirements,  refer  to  the  IBM  General  Purpose  Simulation  System  V-US 
(GPSS  V-US)  Operations  Manual. 
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lo  niinuiize  the  nu'nber  of  control  cards  required  to  use  (iHSS,  the 
following  cataloged  procedure  is  stored  in  the  ASYS-AS^RUCS  (AGRSS) 
library.  This  cataloged  procedure  allov^s  execution  of  a GRSS  job  that 
requires  neither  the  update  nor  the  jobtape  feature. 


//AbPSb 

//b  LXtC 

//STLRLlb 

//U^UTHUr 

//UIUTLR^j 

//uSYi-llMb 

//UKLbTbLu 

//uInTWORK 

//UlhPUl i 

//  RtNU 


HRHC 

RCi(  l=  JAGU 1 V , R ARi  l=  b , R tG  1 <iUK 

UU  uSN=ASYS.GRSS,UISP=SmR 
UU  SYS0UT=A 

Ub  JNn-SYSL)A,SRACL=(  TRK,{iU,lu)) 

UU  UNIT=SYSDA,GHACE=( 1RK,( lU.lU)) 

Uu  Utlll  = SYSuA,SRACE=(  TRK,(lU,lu)) 

UU  UNI  T=(  SYSUA  ,SER=(  UlNTER(j ) ) ,SPACE=(  IRK , ( lU  ,10 ) ) 
UU  UUNAME=bYSlN 


10  invoke  this  cataloged  procedure,  the  programmer  should  set  up  his  deck 
as  follows: 

//  EXEC  AGHSS 

//SYSlu  UU  * 

(GRSS  Model  Statements) 


Ihe  dCL  cards  used  to  invoke  the  GHSS  inodel  at  Collins  Newport  are  as 
tol 1 ows : 


/ $NLA1504  JOH  'WH/SOy  B50l675/i’7i*520873138  XXXOOOt 

T IME--=(4f  01  ) .REG10N=2A0K»MS8LE;VEL=<2»  1 ) 

/ 0RG  = RM108»AC:H0I  D=N0 

/*f  ORMA  1 AL  f IiDNAMK  = nom  PUT  » PRIN  T S 

/ ff  URhAT  PR  f IiriNAMf>SYSM8G  » Fi)RMS=  1 412  " 1 1 ‘T 
/ ^FORMAT  PR  f ITi.iNAMG=Ii(.)U  I PU  T » f QRM8=i  4 1 2/  if  I 
//  EXEC  AGPSS 

//8YSIN  I,iD  * 

REAILUCATE  C:OM»  100000 
UNI.ISI  APS 
'HhUlAIl  A 
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Ttns  procedure  was  Hleci  in  the  user's  library.  Ilie  JCL  cards  should  be 
modified  as  required  tor  tiie  system  used,  especially  the  JOb  card  and  the 
IIAIN  card. 

iJote  that  three  Cirbb  control  statements  are  included.  1 he  remaining  GhSS 
model  program  statements  are  sectioned  into  three  tiles; 

a.  Mle  "Fl'lUUtL"  contains  the  model  statements. 

b.  fill  "XXXXa":  Ihis  tile  is  the  parameter  set  tile  and  is  ditterent 

according  to  the  contiguration  being  modeled.  It  consists  ot  only 
"IfilTIAL"  statements. 

c.  File  “FktPURT"  contains  the  report  formatting  statements  ot  tne  model 
and  the  "Lnu"  statement. 

I he  job  is  submitted  via  ISO*  as  tollows; 

SUbrllT  (TdtL.FMUUEL  ,XXXXX,FkEPURT) 

(i.b.ii  module  activiation 

The  parameter  file,  referred  to  as  tile  'XXXXX'  above,  is  constructed 
according  to  the  systei.i  contiguration  to  be  modeled.  A base  parameter 
tile  consisting  of  ou  sets  of  INITIAL  statements  (one  for  each  parameter 
identified  in  section  d.J)  may  be  duplicated  and  used  to  construct  tne 
modules  to  represent  the  system  configuration  to  be  modeled.  Currently 
there  are  two  base  parameter  files  one  for  signal  processing  and  the 
second  tor  switching.  Each  ot  these  base  files  contain  a set  of  standard 
(predefined)  modules  which  may  oe  activated  by  initializing  the  appro- 
priate parameters.  Thus  the  system  designer  may  use  predefined  modules, 
may  elect  to  modify  them  to  suit  similar  regui rements , or  may  define  a new 
set  of  modules. 

*Kefer  to  IBM  doc.  (jCzo-Ufa*fb-l  US/VS^I  TSu  Command  Language  Ref. 
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base  tile  duplication 
The  two  base  files  are  nai.ied  as  follows: 

a.  Signal  Processing:  XXXXX  = SpMOUULE 

b.  Switching:  XXXXX  = SWI'iOUULE 

The  duplication  command  via  TSU  is  (as  an  example) 

COPY  SPMOUULE. CivTL  NEWiJAME.CNTL 

NEUllAMt  is  the  name  to  be  assigned  to  the  file  that  is  to  be  created  ( 
to  eight  alphaineric  characters  are  allows).  This  newly  created  file  i 
the  parameter  file  used  to  construct  and  activate  the  modules  of  the 
system  configuration  to  be  modeled. 

Z.b.d.ii  Initializing  the  parameters 

As  mentioned  earlier,  the  base  parameter  file  has  INITIAL  statements  f 
each  of  the  21  parameters  defined  in  section  2.s\  a set  for  each  of  th( 
allowable  mooules.  A non-i ni ti al i zea  set  in  the  parameter  base  file  i 
shown  in  Table  Ii.b-1. 

Ihe  INITIAL  statements  are  GPSS  statements  wnich  initialize  matrices. 
a7  identifies  the  row  number  which  is  (for  this  model)  equivalent  to  tl 
module  number.  The  symbol  following  the  row  number  (e.g.,  ACT,  PKI , C( 
identifies  the  column  number  which  represents  a parameter  type  as  showi 
Table  2.b-2. 

In  Table  tne  number  to  the  right  of  the  symbol  (following  the 

comma)  is  the  value  of  the  parameter  to  be  initialized  to. 


c 
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Idb^e  2.b-2  Parameter  Symbols 


rlYTt  COLUMN  SYMmulS 


ACT 

SYN 

1 

ACT  F \/ A T F COLUMN 

PP  1 

S YN 

Pk  lOP I T Y 

CONI 

S YN 

CON  TPOL  1 YFr  C )hsn 

Mf  r-' 

SYN 

‘4 

MLMOp  Y T YPF  C'JL  MM  , 

Y MIOT 

SYN 

s 

Function  mouifii-p  fhp  sta^t 

f-  mmpt 

NYN 

h 

FUNCTION  MijDIFIFp  F >)k  MOUML 

T M 1 NW 

SYN 

I 

FUNCTION  MnOlFItP  FOP  1/0 

intpl 

SYN 

H 

INTFPLOC^  . MOUUt.F  NUMPF  -• 

OMOfi^Y 

SYN 

s 

MOUULF  NP..  . output  TO 

OMA  X 

SYN 

10 

MAxMUM  NUFUF  LF'-'uTh 

halfwopd 

column  symhols 

-xDSiN 

SYN 

1 

NP  PUPOS  INPUT 

pT  1 MF 

SYN 

d 

PFAO  T[ ml 

wOOUT 

SYN 

3 

NP  WOPUS  no  1 PUT 

W T 1 mF 

SYN 

u 

WPITL  TU-iF 

COp**U 

SYN 

'■) 

COMMON  PrAij  COUNT 

C ('w 

SYN 

COMMON  pkitf:  count 

MILLwOPI) 

C()LUMr>)  SYM^iOLS 

1 ITiTh 

SYN 

1 

1 N P U 1 ! f'/  T Y U P I P t P I u iS 

OINTp 

SYN 

OUT  PiJT  J NT  f P0P7  PF  P 1 (Ml 

mot  f M 

SVN 

MOFIULF  PwoCtSS  I IMF 

SOrST 

SYN 

4 

ST  APT  CY(LF  TIMl  of  I- Sr  T 

OOF  S T 

SYN 

OUTPUT  riMF  offsrT 

( YCLY 
t HkOCFSS 

IV  f ' ^ u s 
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Ihe  nunbers  on  the  right  side  ot  the  llilllAL  statements  are  sequence 
numbers  assigned  to  the  statement.  This  number  identifies  the  statement 
wiiicii  is  to  be  edited  (parameter  value  assignment).  Ihe  ISU  instruction 
(in  the  Lull  mode*)  is  as  follows: 

L SLg  IlK  /CUKKEhl  UATA/!<EW  UATA 
for  example: 

C il^iu  /u/i  This  commana  ctianqes  the  U to  a 1,  which  thus  activates 
module  a/.  The  ehtire  nodule  parameter  set  is  initialized  in  this  manner. 
It  is  recommended  that  a comment  be  included  after  the  module  number  to 
identify  that  module.  Comments  are  identified  by  an  asterisk  in  the  first 
col umn.  For  example: 

C lUyu  /*/*  MATCh  FILTER  16UU  CPS 

Arter  all  module  parameter  definitions  have  been  made,  the  new  file  is 
saved  (using  the  SAVt  command)  and  the  simulation  request  may  be  made  as 
described  in  section  I?.b.l. 

In  using  a predefined  module,  tne  same  metliod  of  initialization  as 
described  above  is  used.  The  difference  being  that  certain  parameters 
have  already  oeen  defined.  Any  of  the  parameters  may  be  set  to  the  value 
as  defined  in  the  system  configuration.  As  a minimum,  the  active  (ACl) 
parameter  must  be  set. 

An  example  of  a predefined  module  is  shown  in  lable  Z.^-3. 


•Refer  to  IbM  doc.  GCi!ti-Ub‘+b-l  US/VSz  TSO  Command  Language  Ref. 
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Table  Z.b-3  txample  ot  a Hre-detined  Hodule 
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As  a miniinuni,  statement  »4UttU  (ACTIVE  parameter)  would  be  set  to  a 1.  If 
this  module  is  defined  to  call  anotlier  module,  then  statement  f*4130  should 
be  set  to  the  module  number  to  be  called.  Any  of  the  preset  parameters 
may  be  changed  to  any  value  at  the  discretion  of  the  system  designer. 

I! . 5 . 3 System  Parameter  Initialization 

The  system  parameters  identified  in  section  2.3.4  are  initialized  in  the 
sane  manner  as  described  for  the  module  parameters  described  in  section 
2.5.2.  These  system  parameters  are  contained  in  the  same  files  as  the 
nodule  parameter  files.  They  are  currently  preset  to  the  type  of  system  - 
Signal  Processing  or  Switching.  For  example,  the  Signal  Processing  system 
parameters  are  set  as  follows: 

INITUL  XFTTPFki), 2000000  1 00  MS  PEFIOL) 

initial  XH4.TImF,  7 700  MS  WlJN 

INITIAL  XHtCCwPT.5  SET  WRITE  II  ME  TO  250  NS 

initial  xhT>CmEMT«20  set  COMMON  MfcMORY  TIME 

2.6  Simulation  Model  Evolution 

The  simulation  model  was  initially  written  to  model  the  "st'^awman"  signal 
processing  system  in  the  parallel  bus  architecture.  The  results  showed 
that  tiie  bus  was  less  than  1 percent  utilized.  This  realization  led  to 
redesign  of  the  strawman  signal  processing  system  including  an  increase  in 
processing  load.  To  accommodate  the  rate  change,  the  design  of  a general 
simulation  model  to  accommodate  various  parameters  was  commenced.  These 
parameters  initially  included  the  following: 

1.  Start  Cycle  Time 

2.  Output  Interval 

3.  Priority 

4.  Humber  of  L)ata  Words  Input 


00000030 

000000-*0 

00000050 

00000060 
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b.  Input  I/U  lime 

fa.  Number  of  Uata  Words  Output 

/.  Output  I/O  lime. 

The  above  parameters  represented  all  the  necessary  parameters  of  the 
strawman  signal  processing  system.  However  with  only  titese  parameters  the 
model  and  simulation  matched  only  a system  configuration  as  defined  by  the 
strawman  system,  i.e.  centralized  control  and  distributed  memory. 

lo  provide  greater  flexibility,  four  more  parameters  were  added.  These 
were ; 

1.  Type  of  Control;  Centralized  or  Decentralized. 

I.  Type  of  Memory  Use;  Distributed  or  Coi.wiion 

J.  Number  of  Internal  Reads  and  Writes  (for  use  by  the  module  for 
storage,  status,  flags,  etc.). 

4.  module  activation 

The  latter  parameter  was  added  for  convenience  when  using  a common  library 
ot  preset  modules.  These  library  modules  may  be  activated  in  the  model 
run  uy  initializing  only  one  parameter.  At  the  same  time,  trie  module 
count  was  expanded  to  bu  nodules  available  to  the  general  purpose 
simulation  program.  In  actual  reality,  the  number  of  active  modules  would 
probably  be  mucli  less. 

Next,  it  was  noted  that  a measurement  of  module  execution  time  relative  to 
start  cycle  times  would  be  a useful  tool  for  sof tware/hardware  tradeoffs; 
and  that  in  certain  conditions,  modules  may  be  required  to  start  or  output 
at  a time  interval  offset  from  real  time,  i.e.,  propagation  delay.  Ihree 
more  parameters  were  tnus  added: 
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^ 1.  liocJule  processiiiy  time 

i.  Start  tine  ottset 
s.  output  tine  offset 

Ine  t.iouol  was  furttier  enhanceo  to  acconiioaate  switching  systems.  It  wis 
recunnized  that  switching  system  modules  do  not  operate  on  a fixed  time 
but  rather  on  a variable  time  based  on  message  traffic  input  and  routing. 

I Three  parameters  were  added  to  provide  a tine  distribution  nodifier  and 

data  distribution  modifier: 

1.  Input/Output  lime  di stri l>uti on  modifier 
L.  Module  time  distribution  modifier 
s.  i/U  distribution  modifier 

f Seven  functional  distributions  are  currently  available  (refer  to  table 

a 

Finally,  to  expand  the  module  interconnection  configuration,  the  module 
call  feature  and  interloci'  feature  were  added.  At  the  same  tine  the  queue 
max  limit  was  added  to  halt  the  simulation  if  tne  module  was  falling 
I behind  by  a predetermined  amount.  The  last  three  parameters  added  are: 

I i.  Module  interlock 

^ (L.  Module  cal  1 


•f.  Max  queue  length 

I 

I 

i The  inclusion  of  these  parameters  resulted  in  the  requirement  for 

1 ; 

^ additional  statistical  reports.  Inclusion  of  all  these  optional  features 

I ^ does  not  imply  that  the  generalized  module  program  fits  all  the  needs  to 
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uesign  dno  node!  all  system  configurations.  As  time  evolves,  more  ideas 
and  configuration  connectivity  are  drought  out  along  with  inore  statistics 
and  reports. 

c . 7 design  Lvolution 

Section  b of  this  report  presents  a design  methodology  for  building  a 
modular  system.  Several  nodes  in  tne  design  flow  call  for  design 
verification  using  a simulation  model.  This  section  is  intendf  • to 
further  the  readers  understandi ng  of  how  to  apply  the  system  simulation 
iiiodel  described  above  to  support  design  verification,  at  the  equipment 
partitioning  point  in  the  methodology  flow.  This  model  was  built  to 
simulate  congestion  of  the  comnuhication  path  between  modules.  As  a 
fall-out  Of  this  model,  some  simulation  of  control  flow  and  module 
processing  congestion  is  possible.  Functions  which  do  not  yet  exist  in 
the  model  yet  are  desiraole  and  possiole  in  the  architecture  are  primarily 
concerned  with  control  flow.  Due  to  tiie  diversity  of  techniques  available 
all  cases  have  not  been  covered.  For  example,  if  one  is  using  distributed 
interrupts  feeding  a centralized  control,  statistics  on  the  control  queue 
can  not  oe  measured.  Also  modeling  of  task  suspension  and  priority  within 
this  control  queue  are  not  possible  with  this  model.  Earlier  paragrapiis 
in  this  section  have  described  the  simulator  variables  and  how  to  input  or 
change  the  parameters.  Tnere  are  four  cataqories  of  parameters  available 
to  the  designer: 

1.  Information  arrival  rates 
Processing  times 
a.  module  to  module  data  flow 
4.  Process  control 
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Jata  control,  which  is  trie  control  of  the  movement  of  data  over  tne  bus 
froiii  one  module  to  the  next,  is  built  in  the  simulator. 

Tne  methoo  for  specifying  information  arrival  is  relatively  straight 
forwaro  in  the  model.  Data  is  specified  in  terms  of  arrival  rate  at  the 
module  interface  (with  a distribution  modifier  about  a mean  if  required) 
and  in  terms  of  module  bus  access  or  delivery  time.  The  examples  in 
Appendix  L associated  with  signal  processing  used  the  fixed  arrival  rate 
with  several  runs  illustrating  the  effect  on  bus  utilization  as  a function 
of  intor,.iation  rate.  Trie  switcninq  example  specifies  data  arrival  with  a 
distribution  modifier  about  a mean.  This  distribution  is  modeled  using 
the  variables  associated  with  the  start  input  and  start  output  control 
functions. 

Tne  methoo  for  specifying  processing  time  is  also  straight  forward.  This 
tii.ie  i.iay  also  oe  specifieo  as  a mean  witn  a distribution.  1 he  processing 
time  specification  can  be  used  to  simulate  either  the  tine  to  complete  a 
hardware  computation  cycle  within  a module  or  the  tine  to  complete  a 
software  execution.  In  tlie  hardware  case  this  is  often  not  important  due 
to  double  buffering  and  the  relatively  fast  execution  times  possible.  It 
should  be  noted  that  information  for  specifying  a new  nodule  can  be  gained 
from  a simulation  run  by  setting  the  processing  time  to  zero.  The  time 
then  accumulated  in  the  "lime  Difference"  output  column  specifies  the  time 
available  for  module  computation  if  no  buffering  is  provided  in  the 
module.  For  the  case  when  a processing  time  has  been  specified,  a value 
less  than  zero  in  the  "Time  Difference"  column  indicates  a problem  in  the 
system. 
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The  parameters  which  direct  data  flow  are  used  to  simulate  the  case  wlien 
I/O  times  are  a function  of  bus  time  plus  the  receiving  modules  input 
time.  Since  the  bus  in  this  architecture  is  asynchronous  and  interlocked, 
the  time  to  transfer  a word  of  data  is  calculated  by  summing  the  time  to 
achieve  bus  mastership  + the  bus  transfer  time  (fixed)  + the  time  required 
to  acknowledge  the  transfer.  The  last  function  is  determined  by  either 
the  Masters  output  time  or  the  Slave  input  write  tinie,  wtiichever  is 
greater.  Statistics  are  listed  whicti  accumulated  this  I/O  times  on  a 
given  module,  when  many  outputs  are  directed  to  one  input,  the  sum  of  all 
transfer  times  are  accumulated  on  the  receiving  modules  input  and  listed 
in  the  column  '‘tailing  Hod  I/O  Totals". 

The  process  control  function  is  concerned  with  the  direction  of  execution 
and  I/U  of  algorithm  modules  within  the  equipment.  Appendix  A.l  specifies 
a control  technique  which  is  hignly  desireable  in  a signal  processing 
system.  Tins  control  method  assumes  fixed  rate  execution  times  typical 
for  signal  processing  for  each  task.  By  using  this  technique,  the  control 
is  simple  and  flexible.  Adding  or  deleting  a module  in  this  architecture 
is  achieved  by  changing  the  task  table  in  the  central  control  mooule.  It 
was  found  during  the  modeling  of  switching  systems  that  this  control 
method  does  not  match  the  statistical  nature  of  the  switch.  To  use  a 
centralized  control  scheme  in  a switch  requires  a polling  scheme  to  be 
incorporated. 

Figure  1.4  is  a listing  of  the  various  control  metliods  by  general  catagory 
found  in  systems.  Many  systems  mix  control  structures  between  catagories 
which  complicated  tlie  modeling  process  of  the  control  flow. 
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It  was  toutui  that  the  sii.iulation  iiodel  nathereU  nany  i.ieaninqtul  statistics 
tor  the  signal  processing  system  out  is  somewhat  limited  in  the  types  ot 

I 

control  winch  can  Pc  handlea.  Ihe  examples  shov/n  in  Appendix  L and  which 
are  described  in  section  li.ii  or  this  report  illustrate  the  use  of  the 
model  to  measure  parameters  ot  interest  within  the  equipment. 

. u Summary  ot  s iiiiulation  runs 

Six  oitrerent  but  similar  signal  processing  models  were  simulated.  Inese 
models  are  all  derivatives  ot  the  strawnan  signal  processing  system 
(Mgure  <?.h-l)  uescrioed  in  Appendix  L.  Ihe  results  ot  each  are  sum- 
marized in  laole  z.b-1.  In  the  switching  model  (figures  ano  <^.d-3), 

two  simulations  were  made;  at  peak  hour  load  and  peak  second  load.  Their 
loans  were  based  on  a typical  switching  system  as  described  in  Appendix  F. 
Ihe  results  ot  each  are  summarized  in  lable 

A walk  through  ot  one  ot-tliL-  signal  processing  models  (KUh  1)  will  oe 
discussed,  jne  ditterences  ot  tne  other  signal  processing  models  from  the 
model  discussed  are  sui.nan zed  in  lable 

before  a simulation  ot  a system  can  be  maue,  the  system  designer  must 
design  tne  system  and  prepare  a model  to  represent  that  system.  In  this 
example,  signal  processing  nodules  from  a signal  processing  nodule  library 
are  available  to  tne  system  designer,  lable  Z.a-6  lists  the  types  ot 
modules  available  in  the  bigiial  rrocessinq  library.  Also  refer  to  signal 
processing  module  rile  listing  in  Appendix  l.  The  task  is  to  build  a 
signal  processing  link  that  will  detect  and  error  correct  an  encrypted, 

[■ 
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Figure  2.8  2.  "Strawman"  Message  Center 


Table  2.8-2 


Summary  of  Switching  Simulations 


Simulation  Model 

Percent  of  Bus 
Utilization 

Percent  of  CPU* 
Utilization 

Total 

Pol  ling 

Data 

Busy  Hour 

7.89 

6.27 

1 .61 

24.6 

Busy  Second 

13.02 

6.36 

6.66 

29.5 

Busy  Second  Data  = 4.5  X Busy  Hour  Data 


♦Percent  of  CPU  Utilization  = (2^ CPU  I/O  Times  + Execution  Times)/ 
Total  Time) 


CPU  Modules  - Memory  Management,  Edit/Validation  Scanner,  Edit/ 
Validation,  Logging,  Routing. 


Note:  The  times  listed  in  matrix  "LOCKS"  are  the  total  of  all 

the  modules  that  are  listed  as  being  interlocked  to  chat 
module.  The  total  for  the  CPU  (except  Memory  Management) 
is  totaled  under  Edit/Validation  Scanner. 
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Figure  2.8-3.  Signal  Processing  Modules  for  Systems  Simulation. 
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i-C'.  ' 

IF  PRE-PROCESSING  MODULE 

SAMPLES  DATA  AT  A FIXED  RATE,  FILTEPS 
AND  OUTPUTS  4 SW1PLFS  PER  BAUD  P^TE. 
THERE  ARE  THREE  MODULES  DEFIMED  FOR 
BAUD  RATES  OF  100,  800,  AND  1600. 

MATCHED  FILTER 

RECEIVES  4 SAMPLES  PER  BAUD  INTERVAL 
AND  OUTPUTS  TWO  CHIPS  AT  THE  BAUD 
RATE.  THERE  ARE  THREE  MODULES  DEFINED 
FOR  BAUD  RATES  OF  100,  800,  AND  1600. 

f 

t 

CORRELATOR 

COMBINES  CHIPS  WITH  KEY  AND  SUMS  OVER 
THE  INTEGRATION  PERIOD.  THERE  ARE 
FIVE  MODULES  DEEINED  WITH  VARIABLE 
INTEGRATION  PERIODS,  BAUD  RATES, 
CODING  TYPE  AND  WINDOW  SIZE. 

i i 

KG  DEMULTIPLEX 

PROVIDES  SUMBOL  KEY  AT  THE  BAUD  PATE. 
THERE  ARE  THREE  MODULES  DEFINED  WITH 
VARIABLE  BAUD  RATES  AMD  CODING  TYPE. 

\ 

SYMBOL  PROCESSING 

RECEIVES  DATA  FROM  THF  CORRELATOR  AND 
OUTPUTS  AT  THE  SYMBOL  RATE.  THERE  ARE 
FIVE  MODULES  DEFINED  WIlH  VARIABLE 
INPUT  RATE,  AND  WINDOW  SIZE. 

SYNC  PROCESSING 

RECEIVES  DATA  EROM  SYMBOL  PROCESSING 
AND  PROVIDES  OUTPUT  AT  THE  END  OF  THE 
SYNC  INTEGRATION  PERIOD.  THERE  ARE 
THREE  MODULES  DEFINED,  ONE  FOR  EACH  OF 
THE  BAUD  RATES  100,  800,  AND  1600. 

\ 

• **' 

WORD  PROCESSING 

RECEIVES  DATA  EROM  SYMBOL  PROCESSING, 
FORMS  CHARACTERS  AND  OUTPUTS  AT  THE 
CHARACTER  RATE.  THERE  ARE  THREE 
DEFINED  WITH  VARIABLE  PROCESSING  RATES. 

I 

( 


2-41 


J 

I 


i: 


I 


» 


f: 


bandspread,  antipodal,  phase-continuous  FSK  signal  received  by  a radio 
receiver.  Ihe  specification  of  the  conriuni cation  mode  is  as  follows: 

data  transmission  modulation  rate  = lUU  baud 

correlation  coding  = CO 

data  rate  = .b  sec 

synchronization  window  = a 

(These  parameters  provide  key  word  references  for  a library  search  in  this 
example.  The  reader  need  not  relate  tnein  to  specific  signal  processing 
impl ications) . 

based  on  the  coninuni cation  requirement,  the  designer  selects  from  the 
library  those  modules  that  meet  the  specification.  The  designer  then 
determines  how  to  interconnect  (communicate  between)  these  modules  so  as 
to  provide  a solution  to  the  system  requirement.  Ihe  result  is  a model 
from  which  a simulation  may  be  made.  In  tin's  example,  the  model 
determined  is  sitown  in  Figure 

The  modules  drawn  from  the  library  were  modules  IZ,  13,  14,  15,  16,  17, 

Id,  and  ly.  The  next  step  taken  was  to  copy  the  main  library  file  (see 
Section  i!.b.i:.l).  Each  of  these  modules  are  initialized  to  the  active 
state  (see  Section  Z.'i.Z.Z  on  how  to  initialize  parameters).  Modules  IZ 
through  17  control  parameters  are  initialized  to  1 (centralized  control). 
Since  modules  17  through  19  are  interlocked  (i.e.,  software  modules  in  a 
CHU  module),  mouules  lo  control  is  received  from  module  17,  and  module's 
19  control  from  nodule  Id.  The  control  parameter  for  module  Id  and  19  are 
thus  set  to  Z\  and  correspondingly,  the  interlock  parameter  for  module  Id 
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is  set  to  17,  and  the  interlock  parameter  tor  module  19  is  set  to  18.  Any 
words  sent  between  these  interlock  modules  are  set  to  L)  (refer  input  words 
and  output  words  parameter). 

As  identified  by  the  lines  marked  call  (see  Figures  i!.8.1),  the  module 
output  call  parameters  (byte  parameter  9)  are  initialized  to  the  nodule  as 
shown  by  the  direction  of  the  call  lines.  Since  centralized  control  is 
specified,  the  specification  of  the  output  call  parameter  does  not  cause 
control  to  be  passed,  but  provides  statistics  to  be  accumulated  on  I/U 
transfer  to  the  called  module. 

Priorities  are  set  according  to  the  position  of  the  module  on  the  bus. 

Ihe  closer  the  module  is  to  control,  the  higher  the  priority.  As  seen 
from  Figure  2.8-1,  the  model  shows  module  12  as  the  highest  priority  and 
module  19  as  the  lowest.  The  priority  parameters  are  initialized 
accordingly. 

To  simulate  the  status  panel,  the  command  memory  function  is  used. 
Iherefore,  the  internal  write  parameter  (halfword  parameter  6)  of  each 
module  is  set  to  a one. 

Once  these  parameters  have  been  set  and  the  file  saved,  the  simulation  run 
may  be  submitted  (see  Section  2. 5. 1.1). 

An  example  of  parameter  settings  are  shown  in  Table  2.8-4. 

Ihe  results  of  the  simulation  (refer  to  performance  statistics  of  run  *fl 
in  Appendix  L)  of  this  model,  showed  that  the  total  bus  utilization  was 
J.bd  percent,  of  which  l.Ub  percent  was  used  by  the  centralized  control 
module,  and  1.82  percent  was  used  by  all  tne  modules  in  updating  the 
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Table  if.b-4  Exaaple  of  Module  lb  Paraneter  Set 
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status  panel.  The  symbol  processing  module,  the  sync  module,  and  tiie  word 
processing  module  (modules  1/,  lb,  and  19  respectively)  are  accessed  so 
infrequently,  tiiat  their  times  are  insignificant  compared  to  the  other 
modules.  Tlie  ratio  of  bus  time  used  for  control  versus  data  is  1:2.5. 

This  suggests  that  data  transfer  is  very  tightly  linked  to  control.  In 
this  example  the  total  bus  time  use  is  low,  but  if  bus  use  became  a 
problem,  grouping  modules  to  common  interrupts  would  improve  the  ratio. 

Runs  two  and  three  reflect  the  additional  bus  bandwidth  needed  when  the 
baud  rate  is  increased.  It  can  be  seen  that  increasing  the  baud  rate  by  a 
factor  of  eight  only  increased  the  use  by  one  percent.  This  change  is 
small  because  of  the  small  percentage  of  bandwidth  used  by  the  modules 
that  changed. 

Run  four  illustrates  the  effect  of  moving  a selected  module  from  software 
to  hardware.  The  choice  of  module  to  be  moved  would  be  on  bus  use 
statistics  or  processing  requirements.  As  can  be  seen  in  the  table,  no 
apparent  change  to  bus  use  can  be  seen  by  moving  this  function  from 
software  to  hardware,  indicating  that  bus  use  is  not  a tradeoff  factor  in 
this  proposed  change. 

The  last  two  runs,  five  and  six,  illustrated  an  example  which  points  to  a 
need  for  buffering  on  a module.  Run  five  shows  a -5230  time  units  in  the 
"Time  Difference"  column  of  tiie  run.  This  difference  occurs  with  a fast 
access  correlation  module.  Run  six  slows  the  access  to  the  correlator  and 
assumes  double  memory  buffering.  Ihis  solves  the  data  loss  problem  but 
increased  the  bus  utilization  from  lu.7  percent  to  ib.b  percent.  A check 
of  the  "Time  Difference"  column  indicates  that  I/O  is  complete  between 
output  start  cycles. 
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Table  'd.ti-b  lists  the  modules  (numbers)  selected  from  the  Signal 
Processing  Library  for  each  of  the  six  models.  The  simulation  report  of 
each  (including  tne  listing  of  the  signal  processing  module  library)  may 
be  found  in  Appendix  L. 

In  the  case  of  the  switching  system  simulation,  listed  in  Appendix  L,  it 
can  be  seen  that  the  utilization  of  the  bus  by  the  distributed  control  is 
weakly  dependent  on  the  amount  of  data  being  transferred  through  the 
switcli.  Referring  to  Table  Z.b-l,  it  can  be  seen  that  for  the  increase 
from  busy  hour  to  busy  second,  (busy  second  equals  4.b  times  the  total 
characters  received  during  the  busy  hour)  the  bus  utilization  increases 
from  7.y  percent  to  Id  percent.  This  is  almost  all  as  a result  of 
increased  data  words,  with  internal  data  transfers  increasing  U.l  percent. 
While  it  was  originally  thought  that  a dual  port  memory  was  necessary,  to 
eliminate  contention  between  the  CPU  and  the  Line  Handlers  requesting 
memory  access;  it  is  seen  from  the  simulation  results  that  there  is  no 
foreseeaole  contention  problem. 

Deliverables 

(f.y.l  Listing  of  Program 

Ihis  listing  consists  of  UPSS  statements  of  the  general  simulation  program 
(name  = FMObEL)  which  was  developed  to  represent  the  operation  of  the 
parallel  bus  architecture  and  to  operate  according  to  a set  of  parameters 
for  each  module  activated  in  the  model.  A second  listing  consists  of  GPSS 
format  statements  on  the  construction  of  the  simulation  run  report. 

d.'i.d  Flowcharts 

Ihe  flowcharts  are  the  bPSb  block  and  data  path  diagram  of  the  general 
simulation  program  FllOUEL. 
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Table  2.8-5.  Index  of  Signal  Processing  Models 


Run  Number 

Identification 

Modules  Used 
from  Library  ($NLA1600) 

1 

$NLA1601 

12  through  19 

2 

$NLA1602 

36,37,38,40,44,45,46,47 

3 

$NLA1603 

1 through  8 

4 

$NLA1604 

1 through  8 

5 

SNLA1605 

i 

24  through  29  j 

6 

$NLA1606 

24  through  29  1 

i 

i 


Listing  of  Module  Library 

Two  listings  are  provided.  These  listings  are  the  base  file  used  to 
specify  modules  for  (1)  signal  processing  modules,  and  (Z)  switching 
modules. 

Files  (Magnetic  Type)  of  Program  and  Module  Library 

Source  files  of  the  general  simulation  program,  reports  format,  and  module 
libraries  will  be  provided  on  magnetic  tape. 
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3.U  TASK  III  - LAiJbUAGL  SlUUY 
3.1  Introduction 

This  task  considers  the  mutual  interactions  between  tiie  design  character- 
istics of  High  order  Languages  (hOL's)  and  requi retnents  for  their 
efficient  and  effective  application  to  the  area  of  modular  design  of 
digital  signal  processing  systems  and  message  switching  systems. 

Section  i.Z  is  an  overview  of  various  technical  and  procedural  considera- 
tions involved  in  setting  the  design  objectives  for  a suitable  HOL  and  its 
support  software.  Several  difficulties  are  identified  and  a long-range 
approach  toward  their  solution  is  discussed. 

Section  3.3  presents  the  current  tecnnologies  and  techniques  used  in 
implementing  nodular  systems  for  signal  processing  and  message  switching 
applications.  Three  common  system  archi tectures  and  their  impact  oh  HOL 
design  are  discussed,  followed  by  a comparison  of  three  existing  HOL's. 

Section  j.4  gives  conclusions  and  recomeridations. 

Section  3.b  suggests  areas  where  further  study  of  this  topic  may  bo 
productive. 

J . i Overview,  HOL  besiqh  Requi  rer.iehts 

HOL  design  requirements  must  be  defined  for  the  signal  processing  and 
message  switching  applications  area.  A start  can  be  made  by  comparing 
existing  HOL's 

- to  each  other, 

- to  the  needs  of  the  application  area, 

- to  other  factors  which  increase  its  acceptability  and  usefulness. 
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General 


The  first  step  in  conparing  the  many  available  and  proposed  HOL's  is  to 
discover  and  list  the  features  and  capabilities  of  each  H0L. 

Tne  second  step  is  to  compare  the  lists  against  each  other.  However,  such 
comparisons  cannot  mean  much  unless  there  is  also  a set  of  criteria  which 
allow  the  analyst  to  assign  favorable  or  unfavorable  weights  to  each 
difference  found.  The  question  arises,  how  does  one  formulate  sucn 
cri teri a? 

Une  way  to  proceed  is  simply  to  make  some  preliminary  assertions  about 
wiiat  is  initially  considered  to  be  important,  and  hope  to  refine  the 
assertions  into  criteria  which  will  be  acceptable  to  those  who  are 
interested  in  the  same  applications  area. 

Preliminary  Assertions 
A.  Appl ications  Area 

The  applications  area  is  tliat  of  modular  systems  for  signal  processing 
and  message  switching. 

Al.  System  arclii tectures  containing  multiply-connected  processors  and 
peripherals  must  be  accommodated. 

kd.  Processors  within  the  given  architecture  may  be  similar  to  one 
another  or  may  be  very  different. 

A3,  iiul ti -processing  is  assumed. 

A4.  tvent-driven  multi-tasking  operations  must  be  supported  with  due 
regard  to  priorities  and  contentions. 

AS.  A wide  variety  of  data  types  must  be  processed  and  distributed 
from  place  to  place.  They  include  boolean,  logical,  integer, 
re^l  complex  and  character,  together  with  constructs  containing 
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these  types.  In  addition  the  controlled  transfer  of  machim 
from  sour(?e  to  destination  must  be  supported.  Bit  manipula 
and  precision  control  are  required. 

Bridging  conventions,  hardware/software . 

Before  the  software  designer  can  instruct  elements  of  the  system 
perform  the  tasks,  he  must  have  a defined  interface  to  access  th' 
tasks. 

Consider  the  time-honored  precedent  for  the  assignment  of  a proci 
a specialized  hardware  module,  namely,  floating  point  hardware, 
hardware  designer  provides  the  instructions  which  are  symbolical 
known  as  PAUL),  FSUB,  FIlUL  and  FuIV  for  ttie  use  of  the  programmer 
(Note  that  the  programmer  often  does  not  care  whether  these  insti 
tions  invoke  hardware  or  trapped  subroutines,  provided  that  the 
interface  and  functions  are  identical.) 

Anotner  important  part  of  the  above  package  is  FUCh,  the  floating 
point  divide-check,  which  yields  status  rather  than  causing 
processing. 

Similar  interface  control  instruction  examples  can  be  found  in  tl 
usual  1/U  conventions.  These  instructions 

- initiate  actions, 

- provide  status/error  information,  and 

- terminate  actions. 

in  the  applications  area  under  consideration,  the  system  designei 
supply  interfaces  analogous  to  the  above.  The  software  designer 
vitally  interested  in  the  design  of  such  interfaces  for: 


- ease  of  use 

- general i ty/simi 1 ari ty  to  previous  cases 

- all  possible  status  checks,  especially  error  conditions 


The  interface  can  take  various  forms: 

- instructions  (implemented  in  hardware  or  microcode) 

- traps 

- protocols. 

As  far  as  the  software  designer  is  concerned,  the  preferred  methc 

description  is  to  define  the  interfaces  as  if  they  communicated  v 

software  rather  than  the  actual  hardware. 

! Some  preliminary  assertions  about  bridging  conventions  are: 

I 

\ bl.  Interfaces  to  all  actions  to  be  directed  by  software  must  be 

available  to  the  programmer. 

iiZ.  Invocation  of  the  interfaces  must  be  possible  at  the  symbol! 
level . 

bJ.  Sufficient  status  information  to  allow  efficient  control  of 
flow  of  processes  must  be  available.  Prior  decisions  must  t 
I made  regarding  whether  error  indications  are  simply  indicate 

whether  they  force  actions  to  occur. 

b4.  Interface  definitions  must  include  timing  information. 

> 

bb.  The  bridging  process  includes  the  development  of  an  Operatir 
.if  System  which  performs  most  or  all  of  the  accesses  to  the  abc 

interfaces.  Ine  Operating  System  itself  should  be  written  i 
Chosen  HUL  to  the  greatest  possible  extent. 


The  Operating  System  normally  provides  software  interfaces  to 
Applications  software  modules,  which  communicate  to  it  by  means 
such  as  request  packets.  Such  packets  must  be  supported  by  the 
Chosen  hUL. 

C.  Compiler,  rtUL , and  support 

Ihe  choice  and  implementation  of  a suitable  hOL  should  be  in  the 
context  of  widely  accepted  current  principles.  The  study  of  candidate 
tiOL's  is  one  source  of  such  information;  the  general  literature  is 
another. 

Cl.  Ttie  overall  intent  of  the  L)oU  efforts  to  specify  a common  HOL  for 
imbedded  processors  is  directly  applicable  to  this  applications 
area.  An  interpretation  is  given  in  section  J.2.3. 

C2.  Block  structuring  must  be  possible.  This  not  only  allows  for  the 
use  of  top-down  design  methods,  but  provides  for  the  future  use 
of  foHiial  program  verification  techniques. 

C3.  Compile-tine  error  analysis  should  be  as  helpful  as  possible. 

Ihe  strong  type-checking  features  of  several  recent  HUL  compilers 
is  a good  example. 

C‘*.  Escape  mechanisms  from  trie  hOL  language  rules  must  he  formalized, 
ana  instances  of  their  use  must  be  highlighted  in  the  program 
listing.  * 

Cb.  generated  code  for  cases  within  the  defined  scope  of  the  HUL  must 
be  demonstrably  efficient  enoiigli  to  discourage  the  use  of 
escapes.  As  a minimum,  an  optional  printout  of  generated  code 
must  be  available  for  the  programmer's  use  in  validating  that 
efficient  code  has  been  produced.  The  most  convenient  format  is 
to  have  the  code  resulting  from  HOL  statements  immediately  follow 
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tt>e  statement! s)  that  generateo  it,  preferably  in  an 
i ntermedi ate-1 evel  symbolic  form  rather  than  binary  or  hex. 

Cb.  (he  progranr.ier  must  have  control  over  the  form  of  the  generated 
code.  Examples  include  reentrant  code,  open  and  closed  sub- 
routines, etc. 

C> . Ancillary  sofU/are  such  as  linking  loaders  must  prevent  or  at 
least  flag  inadvertent  escapes  from  language  rules  when  linking 
separately  compiled  modules. 

Cb.  Support  software  should  be  designed  for  efficient  use  by  a 
sizeable  programming  team.  Examples: 

Ihe  ability  to  include  a closely  controlled  copy  of  a 
lengthy  data  declaration  into  source  text  prior  to 
conipi  lation. 

Clearcut  sof tware-assi stea  configuration  control 
Optional  cross-reference  table  generation 

Cy.  Execution-time  error  checking  facilities  should  be  addressed  in 
the  design  of  the  overall  system.  Little  more  can  be  said  nere 
since  ttie  details  are  necessarily  too  depenuent  on  a particular 
system  arcni tecfure  and  software  Operating  System. 

A partial  approach  to  tne  problem  is  to  provide  the  means  of 
running  module  checks  on  a host  which  supports  a system  emulator. 

CiO.  Ail  printeu  output  should  be  designed  to  serve  directly  as  a part 

of  the  total  program  documentation  package. 

« 

3 . i! . 3 Choice  of  langg.ages  tor  comparison 

A number  of  candidate  HOL's  were  examined  with  respect  to  the  foregoing 
assertions.  Large  areas  of  overlap  were  found  that  satisfied  many  of  the 
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prel  itnitiary  assertions.  Comparisons  here  tended  to  produce  “distinctions 
without  a difference"  in  the  essential  power  of  expression.  Some  HOL's 
were  dropped  simply  because  they  satisfied  few  assertions  or  violated 
others,  and  were  poor  prospects  for  reworking. 

Wnat  emerged  was  the  gap  between  required  features  and  a "composite-  best" 
of  the  available  HUL's.  It  was  concluded  that  without  generating  a 
detailed  ranking  of  all  candidates,  the  main  attributes  of  interest  could 
be  highlighted  by  selecting  only  three  HOL's:  PL/I,  COL  and  SHL/I.  (See 

Appendix  M for  a more  detailed  description  of  the  selection  process.) 

Comparison  of  these  HOL's  can  be  expected  to: 

Demonstrate  trie  direction  of  needed  revisions  or  additions  to  existing 
HOL's  and  their  supporting  software 

iielp  refine  ttie  oreliminary  assertions  into  more  generally  useful 
cri teria. 

An  interpretation  of  assertion  Cl  is  appropriate  at  this  point  because  of 
its  impact  on  the  way  that  software  should  be  implemented: 

uou  Directive  b000.2!D,  "The  llanagement  of  Computer  Resources  in  Major 
Defense  Systems"  applies. 

Life-cycle  costs  of  software  for  imbedded  processors  shall  be 
minimized.  Life  cycles  are  15  to  iJU  years. 

Long  tenn  reliaoility  and  maintainability  are  important  life-cycle 
cost  factors.  So  is  flexibility  in  the  event  of  future  changes 
required  to  respond  to  currently  unknown  future  threats. 
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A baseline  of  well-tested  "correct"  software  nodules  should  and  will 
become  part  of  the  L)oU  inventory,  with  resultant  decreases  in  software 
acquisition  costs  and  improvements  in  reliability.  (To  paraphrase  an 
observation  made  by  N.  Wirth,  designer  of  the  Pascal  language:  the 

probability  that  a given  piece  of  software  is  unreliable  is  precisely 
the  probability  that  its  incorrect  parts  are  executed.) 

The  way  to  accomplish  life-cycle  goals  is  to  use  an  approved  HOL 
together  with  appropriate  documentation. 

Escapes  from  this  MOL,  especially  ingenious  ones,  jeopardize  the 
goals. 

All  software  elements  are  included;  it  is  not  acceptable  to  claim  that 
certain  items  such  as  the  Operating  System  are  excluded  from  life- 
cycle  maintainability  ana  flexibility  requirements. 

Inus,  assertion  Cl  puts  a heavy  weight  on  what  is  probably  the  acid  test 
for  a HOL,  namely  that  an  acceptable  Operating  System  can  be  written  in 
it. 

Each  of  tne  three  languages  has  many  of  the  required  capabilities.  Eacii 
requires  escapes  to  machine-oriented  code.  It  is  difficult  to  conceive  of 
a relatively  stable  hOL  which  would  not  require  such  escapes  in  this 
application  area. 

Therefore  tne  integrity  of  the  escape  mechanisms  is  a major  item  of 


concern  if  assertion  Cl  holds. 
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The  primary  reasons  these  particular  languages  were  chosen  here  is: 

PL/1  - Wide  implementation  and  use. 

SPL/I  - Implemented,  authorized  for  use.  { UoU  Instruction  bUUU.31) 

COL  - Pest  treatment  of  machine-oriented  code. 

In  addition,  each  of  them  has  a variety  of  algorithmic  and  data  handling 
capabilities,  as  shown  in  Appendix  M. 

It  should  be  noted  here  that  a trend  toward  implementing  Operating  Systems 
entirely  in  special-purpose  hardware  is  lixely  (Hot  ROM  or  microcode). 

Such  standard  hardware  modules  will  impact  single-processor  architectures 
and  change  the  role  of  riOL's  in  this  case.  It  is  not  clear  how  multiple- 
processor  Operating  Systems  will  be  affected. 

Overview  of  "Bridging" 

The  bridging  procedures  deal  with  S/H  ( sof tware/hardware)  interfaces  and 
with  S/S  ( software-sof tware ) interfaces.  The  steps  include: 

a.  Tlie  chosen  architecture  is  analyzed.  Processes  to  be  controlled  by 
software  are  identified  and  defined. 

b.  Ihe  S/H  interfaces  are  identified  and  characterized.  The  binary 
formats  of  new  instructions  or  protocols  <ire  defined.  It  is  very 
desirable  that  a S/n  interface  should  look  identical  to  a S/S 
interface.  In  many  cases  the  most  cost  effective  solution  is  to  force 
this  constraint  on  the  hardware  design. 

c.  riardware/sof tware  tradeoffs  are  studied,  with  a probable  return  to 
step  a. 

d.  The  means  of  implementation  of  each  S/H  interface  is  chosen.  The 
cnoices  normally  include  inicro-code,  assenbly-langiiage  routines  or 
linkages,  and  compiler  options/modifications. 
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e.  SymDolic  references  to  S/n  interfaces  are  devised  and  documented. 

f.  Implementation  of  new  HOL  compiler  options  and  modifications,  if  any. 


can  now  begin.  Example:  a built-in  function  which  produces 

appropriate  machine  code  upon  the  recognition  of  some  new  (HOL) 
symbolic  reference. 

g.  A design  plan  for  the  Operating  System  is  generated.  Factors  in  the 
design  include: 

- use  of  available  systems  or  modules 

- distributed  or  symmetric  versus  centralized  control 

- use  and  control  of  escapes  from  the  HOL 

- definitions  of  S/S  interfaces 

- test  and  acceptance  plans. 

At  this  point,  work  can  be  progressing  on  three  software  fronts:  the 

Operating  System,  the  Applications  programs,  and  the  riOL  compiler. 

The  Support  Software  Proliferation  Problem 

In  government  applications,  it  is  often  a contractual  requirement  to 
deliver  tne  nOL  compiler  and  other  support  software  along  with  the 
operational  software.  In  addition,  formal  documentation  of  all  software 
is  usually  required.  Reference:  LioU  Directive  bUU.iiy,  section  V.E. 

This  brings  us  to  an  unpleasant  contradiction  wtiich  is  inherent  in  the 
preliminary  assertions: 

On  one  hand,  we  wish  to  standardize  on  a HOL  and  build  a well -tested 
baseline  of  standard  software  modules  for  the  use  of  system  designers 
in  this  applications  area.  We  hope  to  minimize  the  huge  direct  and 
indirect  costs  associated  with  constant  reinventions  and/or  modifi- 
cations of  equivalent  software  functions. 


I 
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On  the  other  hand,  we  are  talking  about  conpounding  the  problem  by 
supplying  a new  version  of  a nOL  compiler  tor  each  new  complex 
architecture,  or  even  worse,  tor  each  new  version  of  a system. 


When  we  consider  this  in  terns  of  <^0  year  life  cycles  and  the  number  of 
systems  (and  their  versions)  which  will  be  using  imbedded  processors,  we 
can  appreciate  tlie  urgency  of  finding  a workable  compromise. 


What  IS  needed  is  an  overall  approach  which  will  localize  and  limit  the 
modifications  for  each  case.  The  following  points  can  be  made: 

(a)  The  current  UoL)  efforts  to  standardize  instruction  sets  is  an 
encouraging  development.  For  example,  the  joint  Uavy/Army  team  which 
studied  the  choice  of  a "standard  instruction  set  archi tecture" 
selected  the  HUH-li  set.  (This  does  not  mean  that  each  system  has  to 
contain  a PUF-ll;  any  other  CPU  capable  of  supporting  the  instruction 
set  may  be  used). 

(b)  oiven  a reasonably  small  number  of  different  instruction  sets,  the  ap- 
proach taken  by  the  designers  of  the  language  COL  is  very  interesting. 

iriefly,  CUL  addresses  the  question  of  machine  oriented  code  in  the 
f ol 1 owing  way : 

Ihe  compiler  generates  all  object  code;  no  intermediate  level 
assempler  code  is  permitted. 

Tiie  reserved  words  "CuuE  XXX"  and  "Euu"  bracket  the  machine 
oriented  source  code  statements.  The  "XXX"  modifier  specifies 
the  target  instruction  set. 

The  programmer  has  symbolic  access  to  all  instructions,  including 
those  for  register  manipulations,  interrupt  processing  and  abso- 
lute address  assignment. 
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Reasonably  high  level  syntax  is  provided,  tor  exanple; 

X :=  A + b ; 11-  0VERFLU_  IHEli  bO  TO  ERROR; 

A macro  facility  is  provided 

And  most  importantly,  the  compiler  can  maintain  most  language 
rules  (such  as  type  checking)  witnin  the  CODE.... END  bracket. 

(c)  It  we  extend  this  idea  to  a distributed  architecture  and  call  tor  the 
HOL  to  support  arcni  tecture-onented-code  (AOC)  statements,  we  will 
have  succeeded  in  localizing  and  limiting  the  modification  area  while 
retaining  most  ot  the  benefits  of  using  a HOL. 

Any  escape  method,  including  this  one,  gives  the  programmer  the  power 
to  defeat  the  intent  ot  the  HOL.  However,  in  this  case  the  compiler 
has  an  opportunity  to  issue  warnings  and,  in  general,  make  potential 
sources  of  error  higiily  visible  in  the  program  listing. 

With  careful  design  of  tne  AOC,  it  may  be  possible  to  cover  whole 
classes  ot  architectures  with  one  version  of  the  AOC.  This  would  help 
contain  the  hoL  compiler  proliferation  problem. 

This  long-range  approach  would  require  agreements  between  vendors  and 
customers  if  it  is  to  be  of  value.  The  alternative  is  to  learn  to 
cope  with  a growing  collection  of  mixtures  of  compilers,  assemblers 
and  other  support  software  over  the  long  term. 

J.a.b  Software  development  Practices 

(a)  The  hul/AOC  approach  described  aoove  is  only  a tool.  It  can  be  used 
to  produce  good  software  only  it  certain  programming  conventions  and 
disciplines  are  enforced. 
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In  this  applications  area,  "good”  software 
i s modular, 

is  well  structured  and  efficient, 

tias  program  listings  and  associated  printouts  which  are  readable 
and  easy  to  understand,  and  is  well  documented, 
is  potentially  portable  to  another  system  at  a reasonable  cost, 
and 

has  a discipline  of  programmer  accountability  which  is  maintained 
over  the  life  of  the  system. 

In  theory,  the  nUL  segments  of  a software  system  are  inherently  quite 
portable,  subject  to  the  usual  warnings  about  differences  in  bits  of 
precision,  etc.  However,  see  (b)  below. 

The  ADC  segments  are  what  alarm  project  leaders  about  as  much  as  the 
mixture  of  Assembly  and  HCIL  code.  To  most  project  leaders  the  thought 
of  a large  hUL  program,  libera’ ly  sprinkled  witn  AUC  segments  at  the 
whim  of  individual  programmers,  is  intolerable.  In  addition  to  in- 
viting excessive  checkout  expense,  it  makes  the  portability  problem 
harder. 

Solutions  lie  along  the  following  lines: 

Limit  the  accountability  for  AOC  segments  to  one  lead  programmer. 
Confine  the  appearance  of  AOC  segments  to  one  region,  say,  up 
f>"ont. 

If  an  AuC  segment  cannot  be  put  in  this  region,  do  everything 
poss.ble  to  advertise  its  existence. 
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Further  restrictions  may  be  desirable,  such  as  using  the  AOC  just  to 
produce  blocks  ot  machine  code  which  can  be  copied  in-line  when  the 
name  is  invoked.  This  would  produce  an  effect  which  is  equivalent  to 
built-in  compiler  functions. 

Systems  are  obviously  more  portable  when  the  Aut  modules  can  be  re- 
placed on  a one-for-one  basis  with  no  changes  to  the  ilOL  modules. 

Also,  as  will  be  discussed  in  section  3.3,  these  module  replacements 
could  take  the  forms: 

software,  different  instruction  set 

micro-code 

hardware. 

(b)  riOL  portability  has  its  problems  in  this  application  area.  The  under- 
lying assumption  is  that  the  transported  HUL  software  will  execute  its 
functions  in  the  same  sequence  and  with  the  same  relative  timing  of 
function  completions.  This  assumption  may  lead  to  gross  inefficien- 
cies. Fcr  example,  suppose  a lengthy  computational  task  "X“,  which 
was  done  by  software  in  the  first  implementation,  is  assigned  to  a 
hardware  module  in  the  new  implementatiotv.  The  unrevised  HOL  calling 
software  will  wait  for  X's  completion  before  executing  the  next  func- 
tion. but  say  the  motive  for  reassigning  the  task  to  hardware  was 
precisely  to  free  the  HOL  for  other  tasks  >/hile  task  X is  in  process. 
In  this  case  we  have  a redesign  effort: 

rework  the  HUl  function  reference  so  as  to  initiate  parallel  task 
X 

maxe  sure  the  hOL  recognizes  X's  completion  and  responses  cor- 
rectly 
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implement  the  tasks  that  execute  in  parallel  with  X 
recompile,  retest,  redocument,  etc. 

We  could  argue  that  task  X sliould  have  been  designed  as  a parallel 
software  task  in  tne  first  place  to  allow  for  this  type  of  modular 
conversion.  Realistically,  however,  the  extra  overhead  involved  in 
treating  all  possible  candidate  tasks  (multiply?  divide?)  in  this  way 
could  not  be  supported. 

In  addition,  task  X may  not  really  need  to  complete  quickly,  and  a 
slow  but  inexpensive  piece  of  hardware  can  be  used.  In  this  case,  the 
redesign  effort  described  above  would  no  doubt  be  mandatory. 

(c)  Figure  3.Z-i  shows  typical  software  paths  and  the  tools  used  during  a 
software  development  cycle.  The  functions  Editor  through  Emulator  are 
usually  carried  out  on  a large  host  mactiine.  The  executable  software 
ready  for  hardware/sof tware  integration  is  usually  loaded  by  some 
special  means  from  media  such  as  magnetic  tape,  paper  tape,  or  disxet- 
tes . 

The  accessibility,  completeness  and  ease  of  use  of  the  softwart  : 
heavily  influences  both  cost  and  schedule  factors  in  a deve'  ■ 
cycle. 

Iransportabi 1 i ty  of  the  tools  themselves  is  a consi  - • 
design.  It  is  common  to  write  compilers,  assi 
erators,  linkers  and  emulators  in  Fortran  ■ 

(not  its  suitability).  File  hanuM  :.  .1* 
usually  provided  as  standard 


ROCKWELL  INTCRNATIONAI.  NEWPORT  BEACH  CALXP  COLLINS  B— ETC  F/B  0/» 

study  of  5IBNAL  PROCESSINB  SYSTEMS  ANO  SWITCHE-- ETC(U) 

OCA100-7B-C-0070 

NL 


END 

DATE 

FILMED 

•6^77 


3.3  Use  of  Existing  nOL‘s  in  I'lodular  System  Implementation 
3.3.1  General 

The  preceding  section  discussed  the  overall  characteristics  that  are 
desirable  in  a future  HOL  for  this  applications  area.  A long-range 
approach  was  outlined. 


In  this  section  we  will  proceed  from  the  point  of  view  that  for  the  short 
term  and  probably  much  longer,  existing  techniques  and  technologies  will 
be  used  in  the  design  of  modular  systems.  Mixtures  of  implementation 
technologies  will  be  required  for  the  sake  of  efficiency  and  economy. 
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In  this  environment,  existing  HOL's  such  as  HL/I,  SPL/I  and  COL  have  a 
clear  role  without  extensive  modifications.  A comparison  of  these  lang- 
uages is  provided  in  the  context  of  the  requirements  of  three  representa- 
tive system  architectures  and  the  assertions  of  section  3.2.2. 

3.3.2  System  Modularity  and  HOL's 

(a)  A significant  requirement  and  result  of  modular  systems  is  that  im- 
plementation freedom  exists  within  each  module.  This  implementation 
freedom  enables  a module  to  be  significantly  modified  or  replaced  with 
limited  impact  on  other  system  modules.  Further,  various  implementa- 
tion techniques  may  be  applied  to  various  modules  with  the  same 
limited  impacts.  Therefore,  the  designer  of  a modular  system  is  free 
to  select  hardware  or  software  implementation  for  each  module  and 
among  various  techniques  (TTL,  MOS,  fixed  wired,  programmable.  Micro- 
code, Machine  Language,  Assembly  Language,  and  one  or  more  HOL's, 
etc.)  Thus,  the  design  of  each  module  requires  choices  of  imple- 
mentation based  on  that  module's  function. 
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In  the  case  of  software  systems  and  their  modules,  it  is  practical  to 
consider  four  basic  implementation  technologies.  These  are  HOL,  Macro 
Language,  Assembly  Language,  and  Micro-code.  Each  technology  offers 
unique  documentation,  flexibility  and  efficiency  characteristics.  It 
is  expected  that  sophisticated  software  systems  would  contain  modules 
of  each  type  of  construction.  Thus,  a luO%  HOL  system  is  as  unlikely 
as  a lOU'i  micro-code  system.  A requirement  of  modularity  is  that 
these  variously  constructed  modules  can  be  properly  connected  to  fonn 
a complete  system. 

It  appears  that  each  software  module  construction  can  be  accomplished 
using  a single  technology.  That  is,  a given  module  can  be  constructed 
using  all  micro-code,  all  assembly  code,  all  macro  language,  or  all 
HOL.  The  module  may  interface  modules  constructed  from  another  tech- 
nology but  there  appears  to  be  little  need  for  multiple  technologies 
within  a module.  Further,  it  will  greatly  simplify  the  module 
building  effort  if  technologies  are  not  mixed  within  a module. 

It  remains  necessary  to  connect  between  modules  of  differing  tech- 
nology. (Recall  (b)  above  regarding  interface  definitions.) 

An  example  of  this  modularity  would  contain  mostly  HOL  modules  which 
connect  to  other  modules  by  "built  in  functions"  and  routine  calls, 
per  (b)  below.  The  built-in  function  may  be  constructed  using  either 
macro  language  or  assembly  language. 

built-in  functions  may  in  turn  connect  to  macro  language,  assembly 
language  or  micro-code  modules.  Subroutines  may  be  constructed  from 
HOL  or  assembly  languages  and  may  also  connect  to  modules  of  micro- 
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code.  Thus,  basically  HUL  systems  may  be  supported  by  macro  language, 
assembly  language,  or  micro-code  modules  without  compromising  the  nOL 
modules  since  all  connections  appear  to  be  procedures. 

(b)  built-in  Functions 

built-in  functions  (blF's)  are  compiler  operations  whicli  enable  HOL 
software  segments  to  directly  interface  non-standard  hardware  or  sub- 
routines. In  general,  BIF's  are  not  language  dependent  but  are  pro- 
ducts of  the  implementation  of  each  compiler.  Therefore,  any  MOL  can 
efficiently  perform  most  functions  performed  by  assembly  language  by 
relying  on  appropriate  blF  of  the  compiler  implementation. 

It  is  worth  pointing  out  the  hierarctiical  nature  of  the  software 
technol ogies : 

micro-code  provides  building  blocks  to  be  accessed  by  machine 
code , 

machine  code's  produced  by  a BIF, 

The  BIF  is  invoked  by  a HOL  reference. 

A BIF  usually  appears  in  the  itOL  as  an  ordinary  procedure  call.  In- 
deed, procedures  in  one  compilation  may  be  blF  of  another  compilation 
by  changing  compiler  directives.  A familiar  use  of  BIF  is  the  sine 
function.  This  function  is  often  implemented  as  a subroutine  call 
wtiich  may  appear  in  the  HOL  program  as: 

Y : = Slu  (X)  ; 

As  such,  the  compiler  will  utilize  its  standard  treatment  of 
subroutines  and  SIN  need  not  be  a BIF. 


3-19 


i 


i 

I 


li 

R 

il 


however,  standard  subroutine  linkages  are  usually  quite  general  and 
inefficient  so  a simpler  linkage  is  desirable  for  the  SIN  function. 
This  simpler  linkage  can  be  designeo  and  designated  as  a BIF  to  the 
compiler.  Now,  when  the  hOL  statement: 

Y :=  SIN  (X)  ; 

is  encountered,  the  compiler  will  generate  the  BIF  code  which  happens 
to  be  special  linkage  to  a specially  designed  (in  assembly  language) 
SIN  routine.  If  further  speed  is  desired,  it  is  possible  to  have  the 
BIF  produce  the  entire  SIN  routine  as  in-line  software  so  that  no 
linkage  is  necessary  (in  practice  this  is  seldom  done  for  SIN 
functions).  The  hOL  program  remains  unclianged  throughout  these  tran- 
sitions of  subroutine  design  and  efficiency  trade-offs. 

BiF's  can  also  be  utilized  to  interface  special  hardware  or  computer 
instructions  (e.g.,  INTERRUPT).  For  example,  if  a hardware  in- 
struction is  available  which  performs  the  SIN  function,  say  using 
microcode,  the  compiler  can  recognize  SIN  as  a BIF  and  produce  that 
instruction.  Thus,  the  nUL  software  remains  unchanged  through  further 
improvement  of  the  SIN  efficiency. 

Another  example  of  a BIF  is  an  "interrupt  return"  function  to  be  used 
in  a multiple-stack  environment.  The  call  to  the  function  would  look 
like 

INTRTN  (STACK. DESCRIPTOR); 

Tne  resulting  machine  code  loads  the  stack  descriptor  and  then  invokes 
the  machine's  interrupt  return  switching  mechanism. 
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Built-in  functions  are  best  considered  as  macro  instructions  which  can 
be  interpreted  by  the  compiler  to  generate  the  appropriate  assembly 
language  sequence.  The  definition  of  these  macros  determine  the  BIF 
and  provide  a HOL  interface  to  various  implementations  of  other 
modules  (e.g.,  in  this  example  the  SIN  module).  It  is  important  that 
these  macro  definitions  be  carefully  organized  and  controlled  by  the 
system  designer.  (See  Section  3.2.6(a).)  It  is  also  important  to 
provide  convenient  methods  for  coding  these  macros.  The  Machine-like 
Code  feature  of  COL  appears  to  be  an  excellent  candidate  for  a lang- 
uage to  define  BIF. 

3.3.3  System  Architectures  and  HOL's. 

(a)  The  simplest  system  architecture.  Figure  3.3-1,  consists  of  a 
single  computer  which  contains  various  algorithms  required  for 
the  specific  processing  task. 

To  provide  more  parallelism,  speed,  etc.,  some  of  the  algorithms 
may  be  “extracted"  from  the  main  program  and  implemented  in 
fixed-wire  hardware,  or  "algorithm  boxes".  Assembly  language  or 
BIF's  are  used  to  connect  tne  processing  software  to  the  algo- 
rithm units. 

I/O  hardware  may  also  require  HOL  support.  As  requirements 
change,  the  algorithm  boxes  may  be  expanded  and  themselves  become 
processors  with  alterable  software.  Clearly,  the  hOL  must  allow 
the  modification  and  implementation  of  these  processors  with 
minimum  impact  on  existing  software. 
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Figure  3.3-1.  Simple  Architecture. 


(b)  The  pipelined  architecture  (figure  3.3-2A)  is  usually  used  for 

signal  processing.  It  has  the  following  characteristics: 

1.  A limited  number  (usually  1)  of  higher  speed  inputs; 

2.  Incoming  data  is  sequence  dependent;  i.e.,  if  input  b to 
processor  P follows  input  a,  then  output  P(b)  must  follow 
output  P( a) ; 

3.  The  pipeline  may  fan  out  to  several  parallel  outputs.  Per- 
haps in  this  case  it  is  best  to  consider  the  structure  as 
one  pipeline  feeding  into  several  other  processors,  as  in 
Figure  3.3-2B; 

4.  The  system  is  usually  non-homogeneous ; that  is,  composed  of 
processors  that  are  unlike; 

b.  The  various  hardware  elements  usually  have  fixed  task 
assignments; 

6.  Fault  tolerance  may  be  unnecessary  on  a per  pipeline  basis. 
Each  process  (P,  Q,  R,  etc.)  is  made  up  of  combinations  of 
hardware  and  software  which  execute  concurrently.  I/O 
between  the  processes  and  control  of  concurrent  execution 
may  be  managed  by  the  HOL. 

(c)  The  Matrix/Array  Architecture  (Figure  3.3-3),  on  the  other  hand, 

is  usually  used  for  message  processing,  and  has  the  following 

characteri sties : 

1.  Many  low-to-medium  speed  inputs; 

2.  Various  inputs  are  timewise  independent; 

3.  Various  outputs  are  timewise  independent; 

4.  Total  load  may  vary  drastically,  in  the  short  term.  Often  a 
long-term  increasing  trend  persists; 
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5.  System  is  often  homogeneous  (i.e.  similar  processors)  or 
nearly  so; 

6.  Task  assignments  are  usually  dynamic; 

7.  Fault  tolerance  is  often  on  a per  processor  basis.  Here,  as 
in  the  pipeline  system,  the  HUL  must  support  I/O  and  concur- 
rent execution. 

Non-Homogeneous  Architecture  and  HGL 

System  architecture  1 (the  simple  system)  presents  few  problems 
to  the  riOL  except  the  control  of  concurrent  processes  and  I/O. 
However,  architectures  1 and  3 are  more  complex  and  so  present 
more  complex  problems  to  the  HOL.  The  most  significant  of  these 
problens  is  the  non-hoinogeneous  environment  presented  by  a non- 
homogeneous  system. 

A homogeneous  system  is  composed  of  similar  processors  having 
similar  scope  and  similar  interconnections.  The  HOL  of  such  a 
system  can  treat  each  processor  identically  and  in  a straight- 
forward manner.  Often,  a homogeneous  system  can  be  treated  as 
little  more  than  a simple  system  with  some  task  assignment 
mechanism.  Little  more  requirement  is  placed  on  the  HOL  of  such 
a homogeneous  system. 

A non-homogeneous  system  presents  a non-homogeneous  environment 
to  the  software  processes  and  control.  This  non-homogeneous 
environment  can  arise  from  several  causes: 


3-26 


0 by  incorporating  processors  that  are  unlike: 
by  original  design  (e.g.,  a pipeline), 
by  evolution  (e.g.,  retrofit  with  newer  hardware), 
by  failure  of  a redundant  processor. 

0 by  design  allowing  dissimilar  scope;  tnat  is,  not  all  memory 
(or  1/0  or  other  resource)  is  available  to/addressable  by 
all  processors. 

0 by  dissimilar  interconnections,  e.g.,  dedicated  slaves. 
Further,  non- homogeneous  systems  are  more  likely  to  have 
fixed-wired  (or  built-in)  task  assignment,  which  may  require  HOL 
interfaces.  Another  task  assignment  alternative  is  to  allocate 
tasks  (either  manually  or  automatically)  at  compile/assemble 
time.  This  requires  the  HOL  or  its  ccxnpiler  to  provide  for  the 
task  assignment  process. 

Compiler  utilization  tor  non-homogeneous  systems  must  ensure  that 
correct  machine  code  is  generated  for  the  correct  processor. 

Data  representations  must  be  compatible  with  the  processor(s)  in 
which  they  reside. 

Software  Architecture  Considerations 

(a)  Contiguous  versus  fragmented  software. 

8y  contiguous  software,  we  mean  that  the  processing  description 
for  an  entire  system  is  described  in  one  program,  and  that  some- 
how the  components  of  this  program  are  mapped,  as  in  figure 
3.3-4,  into  the  various  hardware  components.  The  goal  of  the 
long  range  approach  of  section  3.2  is  to  provide  the  mechanisms 
for  achieving  a contiguous  design,  in  which  we  can  achieve. 
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Figure  3.3-4.  Program  to  Hardware  System  Maooing. 


A unified  description  of  the  total  processing  algorithm 
A convenient  documentation  for  simulation  purposes. 

In  the  near  term,  "fragmented"  software  as  depicted  in  figure 
3.3-5  will  no  doubt  continue  to  be  the  rule.  Here  we  have 
disjoint  program  modules,  one  for  each  processor  in  the  system. 
Here,  software  modules  do  not  communicate  directly,  but  only 
through  the  I/O  connections  between  units. 

Fragmented  systems  require  I/O  queues  for  communication  and 
buffering  of  tasks  and  data.  The  implied  queue  control  should  be 
kept  simple.  For  example,  a hardware  first-in-first-out  (FIFO) 
stack  could  be  used. 

Another  Operating  System  design  area  of  concern  is  the  set  of 
interfaces  needed  for  Applications  programs  to  access  I/O 
functions.  This  interface  must  be  simple  to  avoid  costly  over- 
head. Techniques  include: 

Memory -managed  I/O,  where  I/O  accesses  are  simply  treated  as 
if  they  were  memory  store/ fetches . 

Special  subroutine  calls  with  minimum  overhead 
b.  Influence  of  hardware  architecture  on  HOL  requirements. 

A further  set  of  assertions  are  made: 

0 Simple  architecture: 

L)l:  Procedure  calls  and  bIF's  handle  the  linkages  between 

modules . 
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Jular  Software  Fragments  Dictated  by  Hardware  System  Architectu 


L)2:  Parallelism  in  this  case  would  require  that  the  HOL 


▼ 


4 


i 


* 

(» 


have  provisions  for  parallel  task  control,  namely  the 
mechanisms  for  starting,  stopping  and  synchronizing 
tasks. 

0 Won-homogeneous  system,  multiple  CPU's: 

U3:  If  a common  HOL  is  to  be  used,  multiple  compilers  or  at 

least  separate  code  generators  are  needed. 

04:  A more  likely  situation  is  that  multiple  HOL's  would  be 

used  on  the  basis  of  cost. 

0 Homogeneous  system,  multiple  CPU's: 

05:  Resource  sharing  ana  Load  sharing  imply  that  reentrant 

code  be  generated  to  allow  sharing  of  routines. 

0 Task  assignment,  matching  hardware  system  characteristics  to 
task  requirements: 

Ob:  At  compile  time,  automatically  by  the  compiler,  by 

dissecting  the  program  into  fragments  that  correspond 
to  tasks. 

07:  At  compile  time,  manually  in  the  case  of 

multiple-compiler  systems. 

08:  At  run  time:  the  compiler  would  tag  software 

task-modules  to  identify  which  resource(s)  could 
execute  the  task.  The  Operating  System  would  then 
dynamically  assign  the  task  to  an  available  resource. 
U9:  Both  the  automatic  and  dynamic  approaches  imply  a means 

for  specifying  task  requirements  and  machine  character- 
istics in  the  HUL  source  code. 


I 
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0 I'lemory  managed  I/O: 

UlU;  Requires  the  ability  to  equate  symbolic  names  to 
absolute  fixed  addresses. 

0 Applications  area,  special  requirements: 

Oil:  Signal  processing  requires  that  arithmetic  facilities 
be  available  for  integer,  real  and  complex  arithmetic. 
UIZ:  Message  switching  requires  the  capability  for  character 
handling  and  bit  manipulation. 

3.3.b  HOL  Criteria 

We  are  now  in  a position  to  establish  some  criteria  for  HOL 
comparisons  for  this  applications  area.  Ihey  can  be  derived  from  the 
Preliminary  Assertions  of  section  3.2.2,  as  influenced  by  the  above 
considerations  based  on  specific  hardware  architectures. 

The  objective  is  to  allow  meaningful  comparisons  whichever  of  the  two 
following  (opposing)  viewpoints  is  taken: 

I.  We  want  the  most  powerful  and  wel 1 -designed  language; 

efficient  compilers  and  software  support  facilities  are  sure 
to  follow. 

or  II.  Almost  any  HOL  can  be  caused  to  perform  a given  task;  we 

want  one  with  demonstrated  efficient  implementations  in  this 
appl ications  area . 

Figure  3.3-6  shows  the  criteria  that  have  been  developed,  the 
assertions  that  support  them,  and  a very  “binary"  comparison  of  the 
presence  or  absence  of  this  capability  in  each  language,  where  YtS  and 
MLC  indicate  merely  that  a capability  exists.  For  more  detail  see 
Appendix  M. 
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PL/ 1 

COL 

SPL/I 

Assertions 

1 . 

HOL  mechanisms  for 

YES 

MLC 

YES 

Al, 

A2,  A3 

parallel  task  control 

D2, 

D6,  D7 

2. 

Integer  arithmetic 

YES 

YES 

YES 

A5 

3. 

Real  arithmetic 

YES 

YES 

YES 

A5. 

Dll 

4. 

Complex  arithmetic 

YES 

NO 

YES 

A5, 

Dll 

5. 

Character  handling 

YES 

MIX 

YES 

A5, 

D12 

6. 

Bit  manipulation 

YES 

YES 

YES 

A5, 

D12 

7. 

Precision  control 

YES 

YES 

YES 

A5 

8. 

Controlled  escapes 

NO 

YES 

NO 

Cl 

9. 

Block  structuring 

YES 

YES 

YES 

C2 

10. 

Type  checking 

NO 

YES 

YES 

C3, 

C7 

11. 

Efficient  object  code 

YES 

TBD 

YES 

C5 

12. 

Reentrant  code 

YES 

YES 

YES 

C6, 

D5 

13. 

Support  software 

YES 

TBD 

YES 

C8, 

C9 

14. 

Absolute  address 

YES 

MLC 

NO 

DIO 

15. 

Machine  char  spec 

NO 

MLC 

NO 

D9 

16. 

Built-in  functions 

NO 

MLC 

NO 

D1 

17. 

Transportable  compiler 

YES 

TBD 

YES 

Cl 

NOTES : 

MLC:  Can  be  done  using  COL's  machlne-llke  code  together  with  other  language  features. 

TBD:  To  be  determined.  COL  is  not  Implemented. 


Figure  3.3-6.  Language  Comparisons 
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J.4  Conclusions 


Existing  HOL's  were  studied  in  the  context  of  on-going  UoD  initiatives  and 
the  requirements  of  the  signal  processing  and  message  switching 
appl ications  area . 

A number  of  assertions  were  made  regarding  necessary  and  desirable  hOL 
capabilities  in  this  context.  From  these  assertions  and  the  supporting 
discussions,  a set  of  criteria  was  developed.  Comparisons  of  existing 
HOL's  against  these  criteria  led  to  the  following  conclusions: 

a.  None  of  the  HOL's  studied  met  all  of  the  criteria;  all  would  require 
an  escape  to  some  Archi tecture-Oriented  Code  (AOC). 

b.  Such  escapes  must  be  carefully  controlled. 

c.  The  approach  to  controlling  escapes  should  closely  resemble  that  taken 
by  the  designers  of  COL,  namely,  the  processing  of  AOC  under  the 
auspices  of  the  HOL  compiler  itself. 

d.  By  limiting  the  number  of  different  computer  instruction  sets,  a 
viable  long-range  approach  becomes  possible. 

e.  For  the  purposes  of  this  study,  only  three  HOL's  need  be  considered  in 

detail:  PL/I,  COL  and  SPL/I. 

f.  Of  the  implemented  languages,  SPL/I  most  closely  fits  the  criteria  for 
this  application  area. 

3.5  Recommendations 

It  is  recommended  that  OCA  consider  requiring  COL  to  include  complex 
arithmetic  capabilities  and  a more  explicit  method  of  handling  character 
strings.  If  this  were  done,  it  is  our  opinion  that  COL  would  meet  the 
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criteria  for  this  applications  area  more  closely  than  any  of  the  languages 
studied.  Further,  it  would  be  a strong  candidate  for  the  proposed  set  of 
UoD  standard  languages. 

It  is  also  recommended  that  OCA  consider  a number  of  topics  where  further 
study  would  be  productive  in  the  area  of  Architecture-Oriented  Code: 

a.  define  which  elements  of  AOC  are  most  likely  to  show  a one-to-one 
correspondence  over  a range  of  hardware  implementations. 

b.  Define  the  macro  capabilities  needed  in  the  AOC  for  greatest 
flexibility  and  ease  of  use. 

c.  Define  the  complete  role  of  the  huL  compiler  in  standard  handling  of 
different  AOC  sets,  with  special  emphasis  on  checks,  diagnostics  and 
error  messages. 

d.  h'rovide  examples  showing  iiow  the  implementation  of  the  foregoing 
definitions  can  lead  to  a methodical  and  reliable  tecnnique  for 
converting  an  existing  AOC  module  to  a new  one  which  is  directed  at  a 
different  instruction  set. 
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Action  4 

Tradeoffs 


4.  Mardware/Sof tware  Alternatives 

4.1  Introduction 

Hardware/sottware  tradeoffs  were  identified  as  a part  of  the  architecture 
selection  process,  and  the  system  model  described  in  Section  2 provides 
user  control  of  these  options.  Tlie  purpose  of  this  section  is  to  describe 
(first  in  general  terms)  the  items  of  interest  in  hardware/software  trades 
ana  their  potential  implication.  Subsequently  these  trades  are  described 
for  switching  ana  signal  processing  systems,  and  summarized  for  reference 
purposes. 

Other  tradeoffs  are  discussed  under  the  classification  "hardware/liardware" 
wherein  trades  of  significance  other  than  simple  speed  changes  are 
considered.  Application  of  the  tradeoff  process  is  also  described  as  a 
part  of  the  overall  design  methodology  presented  in  Section  b. 

4.2  hardware  Software  Iradeoffs  and  Their  Implications 

In  a message  switching  system,  all  functions  are  realizable  in  either 
hardware  or  software  once  sufficient  basic  electronic  hardware  exists  to 
perform  minimum  required  functions  (input/output,  storage,  etc.).  Ihis  is 
due  primarily  to  the  fact  that  message  switches  perform  event-driven, 
rather  than  clock-driven,  functions,  and  have  almost  no  requirements  for 
high-speeo,  high-volume  serial  operations  (such  as  multiplications  in  a 
signal  processing  environment)  that  may  dictate  hardware  implementations 
for  speed  considerations.  Since  nearly  all  message  switch  processing 
functions  can  be  implemented  in  either  hardware  (i.e.,  fixed  logic)  or 
software  (i.e.,  programmable  logic  with  stored-program  memory),  tradeoffs 

(can  be  made  on  a cost  basis. 

Hardware  has  certain  advantages  over  software:  it  is  almost  always  faster 

) 
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than  software  in  performinq  a qiven  function,  it  uses  no  additional  system 
resources  (such  as  memory)  other  titan  its  own  integral  circuitry,  and  it 
is  simpler  to  use  from  j control  standpoint.  However,  software  is  more 
flexible  and  adaptaol  . '.elative  costs  of  implementing  a given  function 
in  hardware  or  software  depend  on  the  complexity  of  the  function  and  its 
frequency  of  use  in  the  system. 

Functions  that  are  best  implemented  in  hardware  are  generally  simple  and 
compact,  well-defined  in  terms  of  both  process  and  inputs/outputs,  and  are 
very  frequency  used  in  the  system.  As  functions  become  more  complex  and 
tine  consuming,  less  well-defined,  and  less  frequently  used,  they  become 
more  economical  in  software.  Flexibility  and  adaptability  can  easily  be 
interpreted  in  cost  terms:  every  change  in  process  involves  redesign  and 

remanufacture  if  that  process  is  implemented  in  hardware;  it  involves 
redesign  but  (in  general)  no  remanufacture  if  it  is  a software  process. 
Performance  of  multiple  functions  in  a module  requires  a multiplicity  of 
designs  and  a multiplicity  of  electronic  configurations  for  a hardware 
implementation;  it  requires  only  a single  electronic  configuration  and  a 
multiplicity  of  stored  programs  in  memory  for  a software  implementation. 

Decreasing  hardware  costs  are  being  founo  in  memory  devices  and 
programmable  logic  as  well  as  in  fixed  logic,  so  no  general  conclusions 
can  be  drawn  regarding  hardware/software  tradeoffs  because  of  this  trend. 
Of  greater  importance  to  the  systems  engineer  is  the  question  of  modifi- 
cation and  update  of  both  hardware  and  software.  Costs  in  this  area 
exceed  those  of  procurement  over  a machine's  life  cycle.  Again,  no 
specific  recommendation  may  be  made  via-a-vis  hardware/software . The 
following  points  must  be  considered  to  support  a decision: 
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(1)  Hardware  uoditication  and  maintenance  costs,  when  labor  intensive 
methods  are  used,  will  continue  to  increase.  If  automatic  test 
features  are  built-in  and  they  pass  tests  for  completeness  ana 


programmability  (i.e.  adaptible  to  future  equipment  changes)  costs  may 
be  expected  to  drop  <^U-bO«>. 

(Z)  Software  modification  and  maintenance  expenses,  when  changes  are 

compatible  with  the  oasic  machine,  are  a direct  function  of  the  user's 
familiarity  with  the  code.  Two  areas  will  result  in  excessive  user 
cost: 

(a)  The  programming  task  was  subcontracted  and  the  detailed  code  is 
poorly  understood  by  the  user. 

(d)  a non-standard  (uncontrolled)  compiler  is  used.  (Recognition  of 
D.O.U.  requirements  in  the  future  shoul d mi ti gate  this  problem.) 


Finally,  the  decision  to  implement  a particular  function  in  hardware  or  • 
software  will  depend  on  the  decisions  regarding  other  functions  performed 
in  the  same  module,  a hardware  implementation  of  a given  function  is 
normally  designed  to  perform  only  that  function.  If  that  function  is 
implemented  in  software  instead,  there  is  often  capacity  in  the 
programnaole  logic  to  perform  additional  functions  as  well.  In  these 
cases,  additional  functions  can  be  performed  in  software  at  little 
additional  cost,  almost  certainly  at  less  cost  than  in  hardware. 


4.3  Specific  Hardware/Software  Tradeoffs 
4.3.1  Switching 

The  interface  units  defined  previously  for  each  candidate  architecture 
(MIC  for  the  Matrix,  MIU  for  the  Serial  Bus,  b£U  fo»  the  Parallel  Bus) 
perform  several  functions  which  are  the  subject  of  hardware/software 
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tradeoffs  in  dcsiqintuj  a Message  Switch.  All  the  ititerface  units  may 
perform  address  translation  on  traffic  leaving  the  modules.  Hills  and  oLUs 
may  perform  address  decode  on  bus  traffic  to  determine  if  tne  traffic  is 
intended  tor  their  modules  (it  is  assumed  that  an  MU,  will  not  see 
incoming  traffic  addressed  to  another  module).*  If  the  modules  are  widely 
separated  pnysically,  or  if  the  i'Icssage  Switch  environment  is  electrically 
noisy.  It  nay  he  necessary  to  perform  parity  checks  or  everj  error 
detection  and  correction  (thAL)  fufictions  on  all  traffic.  Fixed  logic 
devices  exist  today  to  perform  simple  (e.g.,  single  cnaracter)  parity 
checks  and  short  (up  to  h bit  code)  polynomial  error  correcting  functions. 
For  these  cases,  hardware  imp'enentations  are  ctieaper  as  well  as  faster 
than  software,  hardware  implementations  may  also  oe  forced  by  processing 
speed  requirements  due  to  high  traffic  volume.  For  more  complex  parity  or 
tUAL  functions,  software  implementations  may  be  more  cost  effective, 
barring  speed  requirements  as  noted  above.  The  parity  and  LUAC  functions 
envisioned  for  the  Fiessage  Switch  outlined  in  Appendix  F will  be  performed 
on  input/output  lines  in  the  Line  and  Trunk  handler  Units,  arm  should  ue 
of  sufficient  simplicity  for  hardware  implementation. 

Two  other  functions  subject  to  hardwarc/sortware  tradeoffs  are  addition/ 
deletion  or  character  start  and  stop  bits  on  asynchronous  lines,  and  coue 
translation  (e.g.,  ASU l/baudot) . both  are  normally  implemented  in  a 
combination  of  hardware  and  firmware. 


A major  consideration  in  these  hardware/sof tware  tradeoffs  is  the 
complexity  (i.e.,  word  length)  of  the  addresses  to  oe  processed;  the  more 
complex  the  addresses,  the  more  likely  is  a software  implementation. 
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4. 3. if  Signal  Processing 


Referring  to  the  selected  architecture,  the  model eo  configurations  allow 
either  centralized  or  distributed  control.  Centralized  control  most 
typically  will  be  used  in  real -time-dri ven  signal  processing  systems  and 
in  similar  systeiiis  cliaracteri zed  by  the  need  to  perform  a fixed 
(non-branching)  sequence  of  operations  in  a relatively  short  period. 
Alternatively,  distributed  control,  wnerein  eacli  module  bids  for  service 
as  a function  of  its  input  data  (or  of  flag  testing),  is  most  appropriate 
for  message  switches. 

It  is  this  difference  of  control  requei rements  that  led  to  the  provision 
for  alternate  mettiods  in  tne  parallel  ous  architecture.  In  terms  of 
physical  realization,  the  centralized  control  can  be  either  hardware  or 
sof tware--the  basic  determiner  being  system  speed  or  allowable  timing 
jitter  on  function  initiation.  Uistributed  control  allows  for  the 
possibility  of  greater  flexibility,  and  in  certain  smaller  systems,  lower 
cost.  It  also  anticipates  the  implementation  of  many  modules  in  micro- 
processor based  hardware,  i.e.,  systems  which  are  easily  adapted  to 
distributed  control. 

A. 3. 3 nardware/Sof tware  Comparison  Summary: 

The  preceeding  material  deals  with  the  tradeoffs  and  alternatives 
associated  with  development  of  the  modular  parallel  bus  system.  Decisions 
concerning  the  desirability  of  tiardware  vs.  software  for  a specific  module 
in  specific  system  applications  will  be  based  upon  the  designer's 
evaluation  of  tnese  and  many  other  related  criteria.  The  methodology  in 


Section  5 is  intended  to  organize  and  quantity  this  effort.  In  addition, 
lable  4.3-1  below  is  organized  to  show  corresponding  decision  types  in  the 
evaluation  of  hardware  vs.  software  for  nodule  design. 
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Table  4.3-1. 


Hardware/Software  Drawing  Types. 


SOFTWARE 


CATEGORY 


HARDWARE 


COST 


1. 

WRITE-IN  j 

1 

1. 

DESIGN 

2, 

PROVE  ] 

NON.HECURRING  1 

1 

2. 

DESIGN  BUS  INTERFACE 

3. 

MEMORY  REQUIREMENTS 

1 

3. 

BUILO/TEST 

4. 

RUN  TIME  ESTIMATE 

RECURRING  ' 

1 

4. 

PRODUCTION  COST 

5.  SYSTEM  SIMPLICATIONS 
- POWER 
SIZE 


REAL  TIME  PERFORMANCE 


NON- 

RECURRING 


RECURRING 


1 CPU  TIME 

2 MEMORY  TIME 

3 BUS  TIME 


1 FACILITY  TIME 
7 EXECUTION  TIME 
3 CONTROL  REQUIREMENTS 


MODULE  INTERCHANGEABILITY 


1 TEST  FOR  COMMON  INTERFACE 

EXCEPTIONS  ARE  COMPILER  VIOLATIONS'  . 
USE  OF  "CLEVERNESS  • WHERE  GOAL  IS 
NOT  explicit 


1 TEST  FOR  COMMON  INTERFACE 

EXCEPTIONS  ARE  RIGIDITY  OF  TIMING. 
NON  STANDARD  (NOT  COMMON  FACILITY) 
I/O.  ETC 


i 


NOTE  INTERCHANGEABILITY  IS  DEFINED  AS  FOLLOWS 

MODULES.  HARDWARE  OR  SOF  TWARE  ARE  PRESUMED 
TO  BE  INTERCHANGEABLE.  i e . ALL  HARDWARE  MODULES 
SHARE  A COMMON  INTERFACE  ALL  SOFTWARE  MODULES 
ARE  DEFINEABLE  AS  SUBROUTINES  AND  ARE  WRITTEN 
IN  AN  HOL  , 


SYSTEM  COMPLEXITV 


1 IMPACT  OF  CPU  (i.a  . CHANGE 
OF  TYPE  REQUIRED?) 

2 HOL  VERSUS^  CODE 

3 EFFECT  ON  SYSTEM  STATISTICS 


1 INVENTORY 

2 STATE  OF  THE  ART  REQUIRED? 

3 SIMILARITY  TO  OTHER  SYSTFM  MODULES 

4 UTILITIES  REQUIRED 

- POWER 

- SPACE 
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4 . 4 Hardware/ Hardware  Tradeoffs  and  Their  Implications : 


Hardware/hardware  tradeoffs  have  been  made  in  three  major  areas  in 
designing  the  Message  Switch  outlined  in  Appendix  F:  Centralized  versus 

Distributed  Memory;  Bus  Access  Control;  and  Process  Control.  All  these 
tradeoffs  involve  alternative  design  philosophies,  not  merely  substitution 
of  different  hardware  devices  which  are  generally  functionally  equivalent. 
The  tradeoff  between  centralized  and  distributed  memory  involves 
considerations  of  bus  contention  in  movement  of  message  blocks,  of  bus 
access  control,  and  of  the  total  memory  required  for  in-transit  storage  of 
messages.  In  a decentralized  memory  configuration,  each  Line  Handler  or 
Trunk  Handler  contains  in-transit  storage  for  its  incoming  messages.  This 
configuration  requires  only  one  transit  on  the  central  bus  for  a message 
between  lines  on  separate  Line  Handlers,  and  no  transits  on  the  central 
bus  for  a message  between  lines  on  the  same  Line  Handler.  Contention  for 
use  of  tiie  central  bus  is  greatly  reduced  from  that  in  a centralized 
memory  configuration,  where  two  transits  on  the  central  bus  (one  from  the 
input  Line  Handler  to  memory,  one  from  memory  to  the  output  Line  Handler) 
are  required  for  each  message.  Distributed  memory  requires  enabling  of 
individual  Line  Handlers  to  access  the  memory  within  other  Line  Handlers 
for  message  movement;  this  interferes  with  the  parallel  processing  of 
messages  in  all  the  Line  Handlers.  In  a centralized  memory  configuration, 
all  Line  handlers  may  access  common  memory,  but  not  each  other's  local 
memory,  and  the  parallel  processing  is  unimpeded.  Distributed  memory 
allows  uynamic  allocation  of  a Line  Handler's  local  memory  to  the  various 
lines  terminated  in  that  Line  Handler,  but  this  scheme  will  invariably 
require  more  total  memory  (impacting  system  size,  cost,  power  consumption, 
reliability,  etc.)  than  a centralized  memory  configuration  where  storage 
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can  be  dynamically  allocated  to  inputs  from  all  the  switch  ports.  It  was 
felt  initially  that  bus  contention  would  not  be  so  serious  a problem  as  to 
require  distributed  memory,  and  so  a centralized  memory  configuration  was 
chosen  for  tlie  target  system.  Subsequent  simulations  of  the  target  system 
in  this  program  have  shown  low  bus  utilization  and  contention,  justifying 
the  clioice  of  centralized  memory. 

Tfie  question  of  centralized  versus  distributed  bus  access  control  is  still 
being  investigated.  While  distributed  bus  access  control  miaht  require 
less  complex  Hardware  and  software  than  centralized  control,  it  is  not 
clear  which  implementation  results  in  less  bus  contention  or  tngher  system 
throughput.  The  switch  simulations  to  date  have  shown  such  low  bus 
utilization  that  a choice  is  difficult  to  make.  The  bus  access  control 
method  is  clearly  not  a limiting  factor  on  system  performance  for  the 
target  system. 

The  question  of  centralized  versus  distributed  process  control  is  also 
still  being  investigated.  In  this  context,  process  control  refers  to  the 
coordination,  assignment  and  initiation  of  individual  process  tasks  such 
as  code  translation,  logging,  and  table  searches.  Process  control  is 
normally  a function  associated  with  the  functional  modules  of  a system  and 
not  with  the  archi tectural  hardware.  (Technical  control,  on  the  other 
hand,  refers  to  those  functions  involved  with  maintaining  the  integrity  of 
the  archi tecture' s transmission  paths,  and  is  normally  associated  with 
some  part  of  the  archi tectural  hardware.)  To  date,  simulations  have 
assumed  distributed  process  control;  the  CPU  and  the  Line  Handler  Units 
operate  in  parallel,  each  driven  by  external  events  (e.g.,  incoming 
messages  from  subscribers  or  other  switches)  or  by  communications  in  a 
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portiun  ot  main  nienory  wtiich  is  periuuically  accessc-fi  by  all  units.  It  is 
felt  that  ai  striiHJtecJ  process  control  is  more  appropriate  to  the  general 
proplen  ot  message  switching,  because  ot  its  flexibility  and  growth 
potential,  nowever,  it  i.iay  be  tfiat  tor  a very  small,  lightly  loaoed 
switcn,  centralized  process  control  could  be  inplenented  in  a snail  CPU 
and  result  in  a less  costly  configuration.  Since  a realistic  simulation 
ot  trie  centralizeu  process  control  configuration  would  require  simulation 
ot  the  internal  processes  ot  individual  nodules  as  well  as  tne  overall 
switcn  arcin' tecture , such  investigations  nave  not  been  done  to  date. 

4.D  Sottware/Sottware  Iradeotrs  in  riessagc  Switcning 

4 . b . 1 Language  Level 

In  developing  tne  software  tor  a message  switching  system  tradeoffs  can  be 
made  between  tne  use  ot  nigh  Order  Languages  (hOL)  and  assembly  languages, 
lo  analyze  tne  tradeoffs,  several  funaauental  differences  between  hUL  ana 
assemuly  languages  must  be  understood. 

Generally,  a programmer  can  develop,  test  and  debug  the  same  number  of 
lines  of  code  in  a given  time  irrespective  of  the  level  of  those  lines  of 
code,  uecause  a nUL  characteristically  will  require  less  lines  of  code 
per  prograi.1  than  assembly,  a manpower  savings  is  realized  by  using  hOL  in 
software  development. 

A iiUL  requires  a greater  object  program  size  tnan  a corresponding  assembly 
language  program.  As  the  cost  of  memory  continues  to  decline  the  program, 
size  becomes  less  critical,  nowever,  in  small  military  message  switches, 
where  space  is  still  at  a premium,  it  may  not  oe  feasible  to  increase  the 
memory  size  to  accommodate  use  of  a liuL. 
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Another  consequence  ot  larger  program  size  is  longer  execution  ties  caused 
by  additional  instructions  that  must  be  executed.  In  most  cases  this 
additional  time  is  insignificant  in  the  overall  performance  of  the  system, 
Une  case  where  this  is  not  true  is  in  the  processing  of  high-speed  data 
lines.  Assembly  language  code  may  be  requirea  in  this  instance  to  meet 
the  speed  of  service  requi rements . 

A primary  advantage  of  itUL  use  is  the  transportability  ot  programs  from 
one  computer  architecture  to  another.  In  small  military  message  switching 
systems  there  is  little  need  for  tliis  transportability  since  most  systems 
are  tailored  to  inatch  a particular  computer  archi tecture . 

une  advantage  of  HUL's  tiiat  is  often  overlooked  is  the  ease  of  docuricnt- 
ing.  tiilitary  message  switching  systems  generally  require  detailed  ano 
complete  documentation  of  all  system  software,  because  of  this  require- 
ment, it  may  be  more  cost  effective  to  use  a nUL  that  would  reduce  the 
amount  of  documentation  required. 

In  conclusion,  tne  system  software  will  contain  a mixture  of  assenoly 
language  anu  iiUL  code.  Ihe  breakpoint  between  their  usage  can  only  be 
determined  from  careful  analysis  of  the  particular  message  switch.  In 
general  , those  sections  of  software  that  receive  the  most  use  should  be 
impleinented  witii  assembly  code.  For  instance,  the  input/output  routines 
and  major  sections  of  the  operating  system  should  be  coded  in  assembly. 

Un  tne  other  hand,  less  critical  software,  such  as  editing  and  routing, 
can  be  coded  wi  tti  a hUL . 
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‘♦.b.i!  Iilcrocoding  lo  extend  huL 

Just  as  traue-otts  between  a hOL  and  assembly  language  can  oe  made,  so  can 
trade-otts  between  assembly  and  niicroprogranmi ng.  Since  mic^oprogranmi nq 
is  used  to  define  the  assembly  language  instructions,  new  instructions  nay 
be  implemented  by  changes  to  the  control  store  where  the  microprograms 
reside.  In  general,  it  is  rattier  difficult  and  tine  consuming  to  make 
these  modifications  on  tne  currently  available  computer  mainframes. 
However,  the  message  switching  application  may  lend  itself  to  the 
development  of  an  extended  instruction  set  that  would  greatly  reduce  the 
execution  time  of  repetitive  sequences  of  code. 


I 


1 


Input/output  processing  is  one  area  that  would  lend  itself  to  improvement 
to  receive  a character  from  a telecommunication  line  requires  upwards  of 
lUU  instructions,  by  performing  all  the  functions  of  these  iUU  instruc- 
tions in  one  new  instruction,  a significant  speeo  improvement  could  be 
real i zeu . 

Table  look-up  or  maintenance  is  another  area  that  could  profit  from 
instruction  extentions.  Combining  the  instructions  needed  to  perform  a 
table  search  into  one  new  instruction  would  offer  reduced  execution  time. 

Carrying  this  concept  farther,  a new  instruction  could  be  developed  for 
eacli  hUL  statement  type.  Ihis  would  allow  the  processor  to  execute  the 
mUL  directly.  Such  an  implementation  would  be  considerably  faster  than  a 
conventional  software  implementation. 

In  conclusion,  microprogramni ng  offers  a powerful  extention  to  a mUL,  but 
is  cost  effectiveness  is  questionable. 
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5.U  DESIGN  METHODOLOGY 


Background 

The  previous  sections  of  this  report  have  developed  the  criteria  for  a 
modular  architecture  which  has  attractive  attributes  for  the  implementa- 
tion of  modular  data  and  signal  processing  systems.  It  is  the  purpose  of 
this  section  to  describe  a design  discipline  or  methodology  which  can 
facilitate  both  the  initial  and  evolutionary  development  of  such  systems 
by  assuring  that  cost  effective  and  technically  adequate  system  designs 
are  produced. 

There  is  an  implicit  methodology  in  any  system  development  endeavor  that 
yields  results;  iwwever,  the  degree  to  which  the  methodology  is  explicitly 
recognized  and  defined  in  order  to  quantify  and  communicate  the  evolving 
design  decisions  can  be  a significant  factor  in  determining  the  degree  to 
which  the  resultant  system  meets  the  needs  of  the  intended  user.  An 
explicit  methodology  defines  the  directed  flow  of  time  sequential  and 
interdependent  development  steps  and  insures  by  quantitative  and  qualita- 
tive evaluation  that  system  objectives  will  be  achieved.  A design 
methodology  may  ttien  be  defined  as  a codification  of  processes,  techniques 
and  approaches  into  a time  sequential  structure  of  interdependent  steps 
which,  wtien  followed,  assure  efficient  transformation  of  well  defined  user 
needs  into  an  effectively  functioning  and  operationally  adequate  system. 


5.2  Definition  of  a Design  Methodology 


For  the  purpose  of  this  discussion,  the  design  methodology  shall  include 
all  necessary  steps  between  the  first  identification  of  an  operational 
user  need  and  the  verification  of  total  system  performance  as  a prereq- 
uisite to  production.  Figure  5.2-1  shows  the  total  design  process  broken 
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DESIGN  SYNTHESIS 

Figure  5.2-1.  Essential  Elements  of  a System  Design  Methodology. 


aown  into  time  sequential  and  interdependent  elements,  tach  element 
belongs  to  one  of  the  three  major  phases  of  the  design  methodology,  the 
results  of  each  phase  being  well  documented. 

1.  System  requirements  oef i ni tion-duri ng  whicn  the  operational  need  is 
analyzed  and  developed  into  clear  and,  to  the  maximum  extent, 
quantitative  statements  of  the  system  requi rements . This  pnase, 
pnncioally  performed  by  the  designated  system  engineering  function 
includes  the  identification  of  desired  constraints  upon  the  subsequent 
design  activity.  Ihe  principal  documentation  of  this  pnase  is  a 
definitive  system  specification. 

2.  Functional  analysi s-ourinq  which  system  level  requirements  are  broken 
down  into  functional  processes  and  algorithms  required  to  transform 
the  input  data  into  the  desired  output  data.  Once  necessary  ‘unctions 
are  identified,  tnese  are  allocated  to  hardware  and  software  modules 
(both  real  and  postulated)  based  upon  the  results  of  trace  studies  on 
alternative  approaches.  Individual  ana  collective  ‘unction  models  a-^e 
constructed  ana  computer-aided  simulations  run  to  validate  the  design 
approach  and  assist  in  trade-off  studies.  The  principal  documentation 
of  this  pnase  is  detailed  specifications  of  hardware  and  software 
modules  consistent  with  system  design  requi rements . 

d.  uesign  syntiiesi s-duri ng  wnicn  detailed  hardware  and  software  logic 
design  is  completed  ana  design  verification  tests  are  performed  at 
module  through  integrated  system  levels.  Satisfactory  completion  of 
this  phase  initiates  production  ana  operational  deployment  and  the 
principal  documentation  consists  of  nardware  ana  software  design 
documentation  and  a fina’  test  ana  engineering  report. 


The  entire  design  process  may  be  viewed  as  the  development  of  progres- 
sively more  mature  models  of  the  object  operational  system  finally 
constructed.  Ihe  final  "hardware"  system  may,  in  fact,  consist  of  special 
hardware-implemented  processing  modules,  general  purpose  processing 
modules  (computers)  arid  program  modules  (software)  wiiich  control  the 
computers.  All  expressions  or  representations  of  tiie  system  design  prior 
to  the  realization  of  verified  operational  system  are  then  "models"  of 
that  system.  The  final  and  most  accurate  model  is  the  set  of  detailed 
design  drawings  from  wiiich  ttie  system  can  be  produced.  The  design 
methodology  must  then  assure  that  in  the  process  of  constructing 
successively  more  complete  and  accurate  models  al 1 system  requirements  are 
properly  weigned  and  incorporated.  This  must  include  cost,  properly 
apportioned  to  tiie  life  cycle  elements.  Factors  such  as  operability, 
maintainability,  reliability,  services  life,  and  projected  application  and 
perfomance  evolution,  which  influence  technical  design,  performance  and 
cost,  must  be  not  oe  omitted  from  early  design  models  or  the  objectives 
related  to  these  issues  cannot  be  achieved.  Ihe  design  methodology  must 
explicitly  'ecognize  the  progressive  model  nature  of  the  design  process 
and  establish  the  discipline  witnin  which  all  system  requirements  factors 
are  adequately  considered. 

t>. j description  of  the  Uesign  i-iethodol ogy 
5.3.1  Introduction 

lable  5.3.1  relates  each  phase  to  its  objectives,  the  pertinent  models  and 
! the  documentation  form.  Rather  than  repeat  the  content  of  that  figure, 

the  following  discussion  supplements  it  by  corrienting  on  particular 

r i 

‘ features  of  the  methodology,  particularly  as  related  to  modular  systems, 

j Mote  that  the  evolution  of  models  proceeds  from  a relatively  simple 

|i 
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The  Relationships  of  Design  Methodology  Phases, 
Objectives,  Models  and  Documentation. 


statement  of  the  user  need  to  a prototype  or  partial  prototype  of  the 
system  itself.  Modularity,  especially  in  large  systems  such  as  message 
switches  having  a multiplicity  of  the  various  module  types,  makes  it 
feasible  to  test  limited  subsets  of  the  total  system  (with  appropriate 
cautions)  to  verify  the  design. 

b.3.2  Requirements  Definition 

Early  in  the  methodology  during  system  requirements  definition,  statements 
of  user  need  and  system  level  requirements  constitute  the  most  accurate 
and  complete  description  of  the  system  possible  at  that  point  in  the 
development  cycle.  It  is  particularly  important  at  this  point  to  maximize 
the  accuracy  and  completeness  of  the  requirements  definition  and  to  docu- 
ment these  unambigiously  in  the  form  of  a System  Requirements  Specifica- 
tion, for  this  statement  of  requirements  subsequently  drives  the  entire 
design  process.  For  the  same  reason,  the  intended  user  must  review  and 
approve  the  system  specification  to  provide  initial  assurance  that  his 
need  will  be  satisfied.  Tables  and  charts  should  be  employed  in  the 
system  specification  to  a maximum  practical  extent  to  concisely  state 
requirements  and  minimize  susceptibility  to  verbal  ambiguity.  High  level 
computer  models  of  the  system  may  be  employed  at  this  time  to  a validate 
gross  system  performance  requirements  in  terms  of  input  and  output 
characteristics  and  to  establish  specifications  for  interfacing  systems. 

The  following  topics  must  be  considered  during  system  requirements  defini- 
tion to  achieve  a complete  specification: 

A.  Interfaces:  a complete  catalogue  of  system  inputs  and  outputs  must  be 

prepared  and  should  include  for  each: 


1. 

1/U  types  and  quantities 

2. 

Signalling  form  and  data  rates 

3. 

Communication  Protocols  (e.g.  SDLC, 

ADCCP) 

4. 

Message  formats  and  codes 

5. 

Message  statistics  (arrival  rate  and 

distribution  and  length 

di stribution) 

b. 

Electrical  characteristics 

/. 

noise  or  error  characteristics 

A tabulation  sucn  as  the  exanple  given  in  Table  5.3-2  is  particularly 
effective  for  this  purpose  and  can  be  later  used  during  partitioning 
of  lines  to  line  handler  modules.  Other  tables  should  be  prepared  to 
relate  message  and  noise  statistics  to  specific  inputs. 

£t.  System  Function:  the  nature  of  the  transformation! s)  performed  by  the 

system  on  data  flowing  through  it  should  be  defined  to  the  extent  that 
the  maturity  of  the  system  concept  permits.  Where  specific  or  quanti- 
tative infomation  is  not  available,  the  need  to  develop  it  should  be 
documented.  Operational  control  requirements  should  also  be  defined. 

C.  Development  Constraints:  As  a minimum,  the  following  kinds  of  con- 

straints should  be  considered  for  specification  as  "givens"  to 
subsequent  development: 

1.  System  architecture,  such  as  modularity,  parallel  bus,  pipelined, 
parallel  processing.  Each  architecture  requires  a description  as 
contained  in  Appendix  A-1. 

2.  Role  of  special  purpose  hardware  versus  program-controlled 
general  purpose  processors  and  specific  hardware  to  be  used. 
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3.  Interface  and  interconnect  standards  to  be  applied  (e.g.  MIL- 
STD-188  series). 

4.  Requirements  to  use  specific  liigh  order  programing  languages  and 
operating  systems.  (DoD  Instr.  50UU.29  and  5UU0.31) 

5.  Specific  processing  algorithms,  hardware  and  software  modules  to 
be  used  from  existing  libraries. 

6.  flaintenance  philosophy  - a figure  of  merit  can  be  developed  as  a 
function  of  the  equivalence  of  the  levels  of  modu 1 ari zation  and 
uf  mai ntenance . 

7.  Schedule  for  development  - Schedule  for  development  and  integra- 
tion may  impact  the  technical  approach.  Compromises  in  perfor- 
mance, future  growth  potential,  cost  and  other  factors  may  be 
required  in  order  to  meet  an  urgent  schedule.  Modularity  permits 
use  of  the  off-the-shelf  hardware  and  software  with  interface 
adaptation  to  the  system  interconnect  scheme. 

tt.  Cost  - System  costs  should  be  allocated  to  system  modules  in  the 
same  manner  as  technical  perfomance  factors  to  establish  con- 
trolled cost  goals.  All  trade-offs  leading  to  firm  module  design 
definition  must  consider  cost  as  a primary  factor.  The  life 
cycle  cost  concept  permits  the  evaluation  of  future  operation  and 
support  as  well  as  current  acquisition  costs.  Specific  goals  for 
future  and  current  costs  permit  design  tradeoffs  which  properly 
weigh  these  cost  factors.  UoU  Life  Cycle  Costing  Guides  LCC-1, 
LCC-2  and  LCC-3  should  be  applied. 

J 5.3.3  Functional  Analysis 

Once  the  system  requirements  are  completely  and  accurately  specified,  the 
j functional  analysis  process  is  pursued  to  achieve  firm  definition  of 
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system  modules  as  a prerequisite  to  detailed  design.  As  a first  step, 
identity  all  the  functional  processes  and  algorithms  required  to  address 
the  system  data  input,  transformation  and  output  requi renents . Also 
identify  the  operational  control  requirements  and  their  impact  on  data 
processing.  When  the  analysis  of  functional  requirements  is  well  in  hand, 
the  relative  roles  of  program  controlled  processors  and  special  hardware 
will  begin  to  be  evident  but  several  alternatives  will  likely  exist.  It 
will  be  necessary  to  mal<e  preliminary  estimates  of  the  timing  and  memory 
load  on  processors  and  the  question  of  how  to  implement  specific 
algorithms  and  processes  will  be  strongly  influenced  by  the  relative 
efficiency  of  execution  in  hardware  vs.  software.  For  example,  execution 
of  the  NbS  data  encryption  algorithm  places  a significant  time  burden  on  a 
centralized  CPU  can  be  allocated  to  a hardware  module  wich  is  accessed 
upon  completion  of  each  data  block  encryption. 

A list  of  functions  or  functional  flow  diagrams  should  be  prepared  which 
straws  how  each  system  output  is  created  by  a transformation  of  system 
inputs.  In  signal  processing  systems,  as  defined  earlier  in  this  report, 
one  input  generally  yields  one  output  after  a fixed  sequence  of  internal 
processing.  In  switching  systems,  however,  the  internal  processing  of 
input  data  nay  vary  depending  upon  several  factors  including  the  nature  of 
the  data  content,  its  source,  its  destination,  its  classification,  time 
periods  during  the  day,  and  operational  control  exercised  by  the  system 
operator.  Each  possible  processing  sequence  must  be  identified  as  a 
function  of  controlling  parameters.  This  kind  of  analysis  leads  to  a 
definition  of  the  system  control  structure.  When  combined  with  input  data 
statistics,  it  also  pennits  a determination  of  relative  utilization  of 
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functions  (loading).  The  models  developed  in  Section  1 and  the  Simulation 
described  in  Section  1 together  form  the  method  to  be  used  for  loading 
analyses. 

A near  optimum  allocation  of  system  functions  to  specific  hardware  ana 
software  modules  (partitioning)  is  possible  by  application  of  the 
functional  flow  analysis  togetiier  with  preestablished  performance  criteria 
including  maximum  interconnect  bus  loading,  maximum  processor  time 
loading,  maximum  memory  utilization,  cost  targets,  etc.  An  important 
attribute  of  the  modular  approach  is  that  previously  designed  modules 
(hardware  and  software)  can  be  selected  or  adapted  to  the  extent  that 
their  use  yields  cost  and  development  time  benefits  without  acceptable 
compromise  of  other  perfonnance  factors.  Where  necessary,  new  modules  are 
designed  (sometimes  coinoi nations  of  existing  modules)  ana  added  to  the 
nodule  library. 

System  management  or  technical  control  functions  must  also  be  identifiw-d 
and  partitioned  in  a way  consistent  with  operation  and  control  concepts. 
Status  monitoring,  adaptive  configuration  switching,  diagnostic  testing, 
fault  isolation,  and  operational  statistics  and  history  keeping  are 
included  in  this  category  of  functiohs.  The  effects  that  these  functions 
have  Oh  system  loadihg  must  be  ihcluaed  when  applying  performance  criteria 
during  system  partitioning. 

As  an  example.  Table  5.3-J  presents  the  criteria  for  allocatihg  input  and 
output  lines  to  line  handler  modules. 

Table  S.'i-d  provides  a sample  structure  for  preliminary  Line/Line  Handler 
partitioning.  The  I/O  lines  should  be  listed,  perhaps  in  descending  order 
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Table  5.3-3.  Line  Handler  Assignment  Criteria 


FUNCTION  CRITERIA 

Maximum  Data  Rate  per  Line  Handler  As  the  number  of  lines  increases  on  a 

given  Line  Handler,  the  maximum 
allowable  data  rate  decreases  (to  allow 
for  internal  addressing  to  separate 
buffers  for  each  line).  For  example,  a 
Line  Handler  with  a capacity  of  one  lb 
kb/s*  I/O  line  with  code  translation 
will  handle  only  about  four  2400  b/s 
lines,  not  six;  it  will  handle  only 
about  six  1200  b/s  lines,  not  thirteen. 

Message  Code  Code  translation  is  normally  performed 

with  a mixture  of  software  and  firmware. 
Grouping  together  lines  with  the  same 
code  (e.g.  ASCII,  Baudot,  Moore)  will 
minimize  the  number  of  Line  Handlers 
containing  the  same  software/f i rmware 
package . 

Line  Rrotocol  Similarly,  protocol  functions  are 

normally  performed  with  a mixture  of 
software  and  firmware.  Grouping 
together  lines  with  the  same  protocol 
wil 1 lower  costs. 

Synchronous/Asyrichronous  Lines  For  convenience,  it  is  usually  best  to 

separate  synchronous  from  asynchronous 
I/O  lines.  Since  the  line  interfacing 
of  synchronous  and  asynchronous  lines 
(and  the  handling  of  start  and  stop  bits 
on  the  latter)  is  normally  a firmware/ 
hardware  function  which  is  preprogrammed 
(by  setting  various  control  signals)  on 
a line-by-line  basis,  and  since  there  is 
no  difference  in  the  circuit  board  space 
required  by  synchronous  and  asynchronous 
receiver/ transmi tters , it  is  not  abso- 
lutely necessary  to  separate  these  two 
types  of  lines.  In  practice,  the  sepa- 
ration of  synchronous  and  asynchronous 
lines  often  takes  place  when  lines 
having  different  codes  are  separated  (in 
2 above) . 

•Current  microprocessor  (bUbUA,  bdOO)  designs  will  handle  two  16  kb/s  I/O  lines 

without  code  translation,  or  one  16  kb/s  I/O  line  with  code  translation. 
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FUNCTION  CR11CK1A 

Line  Electrical  Characteristics  It  is  convenient  to  group  together  lines 

having  the  same  signal  modulations  (e.g. 
conditioned  di phase,  balanced  or 
unbalanced  NKZ),  and  those  having  the 
sane  impedances  and  peak-to-peak  signal 
voltages.  Once  again,  tlie  interface 
functions  are  generally  implemented  in 
hardware  on  a line-by-line  basis,  thus, 
it  is  not  necessary  to  group  lines  this 
way . 

Load  Equalization  Within  the  context  of  the  above 

guidelines,  one  should  try  to  equalize 
tlie  loads  on  the  various  Line  Handlers. 
The  "Load"  is  a combination  of  effective 
data  rate  (data  rate  multiplied  by  usage 
factor),  protocol  overhead,  and  code 
translation  overhead,  and  is  at  least 
partially  a subjective  value.  Common- 
ality of  hardware  among  the  Line 
Handlers  is  desirable  for  minimizing 
costs  of  design,  acquisition,  and 
maintenance.  In  a system  where  Line 
Handlers  are  to  be  designed,  load 
equalization  will  allow  implementation 
of  coi;»Tion  hardware  designs  at  the 
slowest  (and  presumably  least  expensive) 
level.  In  a system  implemented  using 
pre-existent  Line  Handlers  of  coiinon 
design,  load  equalization  will  offer  the 
greatest  protection  against  module 
overflow  under  random  peak  loading 
conoi tions . 
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ot  oata  rate,  ana  the  seven  columns  ot  data  on  each  entered.  I/U  line 
number  1 can  arbitrarily  be  assigned  to  Line  handler  number  1.  The  data 
on  I/U  line  number  i should  be  compared  to  that  on  I/U  line  number  I to 
determine,  on  the  basis  of  the  above  factors,  whether  I/U  line  number 
can  be  assigned  to  the  same  Line  Handler  as  for  I/U  line  number  I.  As 
each  successive  set  of  data  on  an  I/U  line  is  reached,  it  should  be 
compared  to  all  those  above  it  to  determine  it  that  line  can  be  assigned 
to  a previously-numbered  Line  handler,  or  if  a new  Line  handler  number 
must  be  established.  When  all  I/U  lines  have  been  assigned  to  Line 
handlers,  load  equalization  can  take  place  either  by  moving  line  from  one 
Line  Handler  to  another  or  by  consolidating  two  or  more  Line  handlers. 

For  example,  if  there  are  two  Baudot,  two  tloore,  and  twelve  ASCII  lines  in 
a system,  the  Baudot  and  lloore  Line  handlers  could  be  consolidated  inspite 
of  their  differing  codes,  provided  the  total  load  was  not  too  great. 
Successive  partitioning  of  I/U  lines  over  Line  handlers  may  be  done  in  the 
same  way,  using  data  established  in  simulation  or  by  test  bed  experience. 

Computer-aided  simulations  find  maximum  utility  during  the  process  of 
partitioning.  A system  model  is  constructed  based  upon  the  initial  module 
set  selected.  There  may  in  fact  exist  several  module  sets  or  several 
parti tioni ngs  between  hardware  and  software  implementations  which  require 
comparative  evaluation.  Computer  simulation  of  the  system  functions  and 
its  data  inputs  and  outputs  permits  a prediction  of  system  performance 
directly  and  without  extensive  manual  analysis  whicn  may  not  be  tractable 
or  even  possible  and,  in  any  event,  is  error  prone  for  a system  of  any 
size.  Ttie  General  i^urpose  System  Simulator  (GPSS)  is  an  effective  tool 
for  this  purpose  and  was  used  successfully  during  the  Collins  study.  Ihe 
model  requires  accurate  definition  ot  module  input,  output  and  timing 
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parameters;  veritication  is  aided  by  trial  simulations  using  simplified 
system  input  and  timing  conditions,  the  results  of  which  also  serve  as 
"oenciimarks"  for  evaluating  subsequent  and  more  complex  "actual"  runs. 

(The  simplified  switching  system  results  presented  in  Section  i were 
developed  as  model  veritication  aids.)  By  plugging  alternative  module 
sets  anu  input  conditions  into  the  system  model,  quantitative  system 
perfon.iance  prediction  data  are  obtained  and  are  used  to  select  the  final 
partitioning  of  system  functions  into  a set  of  hardware  and  software 
modules.  Ihe  requirements  of  the  System  Specification  and  their  logical 
derivatives  are  the  criteria  applied  to  determine  whether  system 
performance,  as  predicted  by  simulations,  is  adequate. 

In  constructing  simulation  models,  it  is  very  desirable  to  progress  incre- 
mentally fy  modeling  portions  of  the  system  individually  using  simplified 
input  and  output  parameters.  This  not  only  makes  the  process  of  debugging 
more  efficient  but  permits  detailed  performance  of  subsets  of  system 
functions  to  be  evaluated  under  controlled  conditions.  Ultimately,  it  is 
desirable  to  simulate  the  entire  system.  This  may  be  accomplished  by 
linkin*g  together  independent  simulated  subsets  or  by  constructing  a gross 
system  model  for  wi'ich  only  worst  case  {or  other  specific  case)  input, 
output  and  module  operating  conditions  are  treated.  In  the  total  system 
model,  system  management  or  non-processing  functions  must  be  included  to 
evaluate  their  impact  on  total  perfonaance . 

The  objective  of  the  functional  analysis  phase  of  ttie  design  methodology 
is  to  firmly  define  the  detailed  requirements  for  design  of  modular  system 
elements  whose  integration  as  a totally  operating  system  is  confidently 
predicted  to  meet  all  system  specification  requirements.  Ihe  design 
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requirements  for  each  module  are  documented  as  module  specifications,  both 
hardware  and  software.  These  specs  stress  inputs,  outputs,  control  and 

timing,  and  define  internal  module  functions  through  the  use  of  block 
diagrams,  flow  charts,  state  transition  diagrams,  etc.  as  nay  be 
appropriate.  The  standardization  of  hardware  module  interfaces  to  a 
common  interconnect  facility  (e.g.,  a parallel  bus)  simplifies  module 
specs  and  permits  a sharper  focus  on  internal  functions  and  reduces  the 
time  for  their  preparation.  Ihe  nodule  specifications,  supported  by 
simulation  results,  provide  a well  documented  basis  for  T'reliminary  desion 
Review  (PDR).  They  are  updated  as  detailed  design  proceeds  and  eventually 
reside  in  the  module  library  as  the  definitive  module  description  docu- 
ment. The  need  for  discipline  in  preparing  and  updating  nodule  specifi- 
cations is  dictated  by  their  potential  use  in  other  compatible  i;iodular 
systems.  Exploitation  of  modularity  benefits  can  only  be  assured  if 
future  users  have  confidence  in  the  accuracy  and  completeness  of  module 
library  data. 

5.3.4  Design  Synthesis 

This  report  will  not  dwell  on  the  design  synthesis  process  but  it  is 
important  to  point  out  that  benefits  of  nodularity  accrue  during  this 
phase  as  well.  Not  all  detail  designs  are  completed  simultaneously.  This 
is  true  not  only  because  of  varying  complexity  but  also  because  of  the 
practical  limits  of  peak  manpower  loading.  In  systems  of  even  moderate 
size,  design  of  all  hardware  and  software  modules  in  parallel  would 
require  an  extremely  high  peak  manning  in  relation  to  the  program  average. 
An  engineering  organization  cannot  function  realistically  under  these 
conditions  and  tfie  design  load  must  be  spread  out  over  time  to  be  accept- 
able. Wodularity,  with  a common  interconnect  scheme,  permits  an  incre- 


5-16 


mental  checkout  and  integration  ot  module  designs  as  they  are  completed. 
Inputs  to  a module  under  test  can  be  simulated  by  the  control  processor 
when  the  actual  source  module  is  not  available.  Therefore,  meaningful 
system  development  progress  is  not  adversely  affected  by  staggered  design 
completions,  either  planned  or  caused  by  technical  problems. 

AS  actual  hardware  and  software  design  and  integration  progress,  the 
results  of  incremental  test  can  be  compared  with  correspondi ng  simulations 
perfomeu  during  the  functional  analyses  phase  or  with  new  simulation  runs 
using  the  same  system  model,  ui screpancies  between  simulations  and  actual 
hardware/software  perfomance  can  be  reconciled  either  by  design  changes 
or  updates  to  the  system  model.  It  is  desirable  to  continuously  upgrade 
tne  computer  based  system  model  in  order  to  maintain  a simulation  resource 
wliich  can  be  used  throughout  the  system  life  cycle  to  evaluate  Changes  and 
upgrades  prior  to  commitment  to  rinal  design.  Ihe  necessity  and  expense 
of  system  simulator  maintenance  must  be  evaluated  against  the  size, 
complexity  and  operational  criticality  of  a given  system,  liowever. 

b.4  Conclusion 

The  advantages  of  a nodular  system  have  been  expressed  in  terms  ot  reduc- 
tion of  cost  and  time  to  implement  systems  and  tneir  evolutionary  succes- 
sors. Iiodularity  increases  the  potential  for  use  of  common  hardware  and 
software  modules  between  systeiis  within  a generic  class  and  minimizes  the 
impact  of  evolutionary  changes  to  a given  system.  In  order  to  exploit 
these  attrioutes,  system  design  or  design  changes  must  be  conducted  within 
a design  methodology  or  dicipline  which  stresses  the  use  of  available 
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nodules  ana  winch  encourages  the  developnont  ot  standard  or  widely  accept- 
able functional  nooules  and  interconnect  schemes,  sitaulation  systems  and 
high  order  programming  languages,  rather  than  unique  designs. 


during  the  system  detinition  phase,  tne  responsiulc-  system  engineering 
agency  may  impose  constraints  on  system  development  by  specifying  a system 
architecture  which  defines  such  features  as  a parallel  bus  interconnect 
scheme  and  haroware/software  modularity.  Ihese  constraints  should  be 
applied  with  caution,  out  can  ue  justified  by  the  longer  term  benefits 


which  accure  frur.i  a more  stanuardi  zation  design  approach.  Constraints  may 
extend  to  the  definition  of  a specific  bus  implementation,  iiigli  order 
language,  the  use  of  a standard  simulation  system,  and  the  requirement  to 
use  existing  nodule  designs  for  particular  functions.  Such  constraints  at 
this  stage  should  be  judiciously  applied,  however,  to  avoid  premature 
foreclosure  on  valid  design  al ternati ves;  but,  the  ability  to  specify 
these  constraints  helps  to  assure  the  prol i feration  ot  modularity  for  long 
tenn  benefit. 

Significant  advantages  of  modularity  are  realized  during  system  functional 
analysis  and  design  synthesis,  lime  and  cost  to  timly  define  two  system 
designs,  to  predict  perfomance  and  to  synthesize  tne  system  and  achieve 
that  performance,  can  be  significantly  reduced  by  a number  ot  modularity 
effects : 

1.  Once  developed,  a large  library  of  well  documented  hardware  and  soft- 
ware module  designs  provides  a resource  from  which  previously  proven 
designs  can  be  selected  to  a maximum  extend  or,  if  necessary,  can  be 
modified  to  implement  new  system  functions.  Costs  for  new  and 
modified  designs  are  thus  minimized. 
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A prerti  s|)Osi  tion  to  use  existing  nodule  designs  wnere  possible  helps 
to  tomulate  initial  system  partitioning.  It  is  likely  that  the  basis 
tor  modular  partitions  of  previous  system  designs,  of  the  sane  generic 
class  troi.i  which  the  library  ot  nodules  has  been  created,  will  nave 
some  validity  in  a current  system  design, 

J.  Assuming  that  a standard  system  simulation  system  has  been  adopted  and 
tost  simulation  models  for  eacti  library  nodule  are  maintained  (this  is 
hignly  rocontiended)  , tiie  time  to  achieve  oebugged  running  simulations 
ot  new  system  conti gurations  will  be  reduced. 

4.  tven  when  new  modules  are  required  by  a new  tunctional  requirement  or 
tne  need  to  apply  advanced  tecnnoloqy,  exisung  similar  designs  pro- 
vide a basis  ot  approach  wticn  nelps  to  reduce  design  cost  and  risk. 

b.  A library  ot  standard  module  designs  and  tlie  use  ot  a standard  simula- 
tion system  provide  the  opportunity  to  employ  ca.iputer-aided  automateo 
system  design  teciiniques  when  sucri  techniques  become  sufticiently 
mature  to  be  applied  at  the  system  level,  note  one  analogy  to  the 
standard  cell  approach  to  LSI  design  which  has  become  highly  auto- 
mated. For  a bus-oriented  modular  system,  both  power  and  signal 
interconnect  ouses  are  standardized. 

b.  System  modularity,  especially  when  prolirerated  over  many  systems  and 
tlieir  evolutionary  successors,  greatly  simplifies  the  logistics 
support  effort  and  its  associated  costs. 

/.  liany  modules  will  be  designed  with  programmable  features  so  that  ttieir 
function  can  be  adapted  to  a greater  range  of  system  applications. 
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The  trend  to  iiooularity  is  evident  every  where  in  the  electronics  industry 
fron  LSI  standard  cells,  to  IC  packaginq  techniques,  to  microprocessor 
functional  elements,  to  consumer  electronic  equipment.  Ine  essential 
feature  of  nodularity  which  benefits  signal  and  communication  systems  as 
discussed  in  this  report,  however,  is  a standard  electrical  and  logical 
signal  interconnect  scheme  - a bus  - which  achieves  flexibility  and 
adaptability  at  the  function  level  in  system  applications. 


